0

My app communicates with a server over TCP, using AsyncSocket. There are two situations in which communication takes place:

  1. The app sends the server something, the server responds. The app needs to read this response and do something with the information in it. This response is always the same length, e.g., a response is always 6 bytes.

  2. The app is "idling" and the server initiates communication at some time (unknown to the app). The app needs to read whatever the server is sending (could be any number of bytes, but the first byte will indicate how many bytes are following so I know when to stop reading) and process this information.

The first situation is working fine. readDataToLength:timeout:tag returns what I need and I can do with it what I want. It's the second situation that I'm unsure of how to implement. I can't use readDataToLength:timeout:tag, since I don't know the length beforehand.

I'm thinking I could do something with readDataWithTimeout:tag:, setting the timeout to -1. That makes the socket to constantly listen for anything that's coming in, I believe. However, that will probably interfere with data that's coming in as response to something I sent out (situation 1). The app can't distinguish incoming data from situation 1 or situation 2 anymore.

Anybody here who can give me help me solve this?

Scott Berrevoets
  • 16,921
  • 6
  • 59
  • 80

1 Answers1

1

Your error is in the network protocol design.

Unless your protocol has this information, there's no way to distinguish the response from the server-initiated communication. And network latency prevents obvious time-based approach you've described from working reliably.

One simple way to fix the protocol in your case (if the server-initiated messages are always less then 255 bytes) - add the 7-th byte to the beginning of the response, with the value FF.

This way you can readDataWithTimeout:tag: for 1 byte. On timeout you retry until there's a data. If the received value is FF, you read 6 more bytes with readDataToLength:6 timeout: tag:, and interpret it as the response to the request you've sent earlier. If it's some other value, you read the message with readDataToLength:theValue timeout: tag:, and process the server-initiated message.

Soonts
  • 20,079
  • 9
  • 57
  • 130
  • The current protocol actually has something very similar to your solution. While it's not exactly the same, I think I know how to implement this now. Thanks a bunch! – Scott Berrevoets Nov 16 '12 at 20:35
  • It appears that after I called the initial `readDataToLength` (for just the 1 byte to see how many more bytes I need to read), further calls to `readDataToLength` are ignored. If I call `[socket readDataToLength:bytesExpected withTimeout:-1 tag:0]`, I still only get 1 byte at a time. (Oh, and I assume you mean `readDataToLength`, and not `readDataWithTimeout`?) – Scott Berrevoets Nov 16 '12 at 21:45
  • You need to to following, in that order: 1. Issue a 1-byte read request to read the header. 2. Wait for the data. 3. Issue a n-bytes read request. 4. Wait for the data, receive the data buffer. I have a feeling you either forgot step #2, or that your code tries to read both response and server-initiated messages in parallel (you definitely need to serialize read access to the socket). – Soonts Nov 16 '12 at 22:07
  • Believe it or not, I do exactly that. I use tags to distinguish a header from "data" and it appears that the whole thing is being read with the header tag. I'm also not the only one with this problem: http://stackoverflow.com/questions/6784872/cocoaasyncsocket-and-reading-data-from-a-socket. Although I'm not using Erlang, I do have that same problem. – Scott Berrevoets Nov 16 '12 at 22:21
  • Problem solved, had another call to readDataToLength which messed everything up. Thanks again for your help! – Scott Berrevoets Nov 16 '12 at 22:55
  • You're welcome. Yeah, when developing an asynchronous code it's easy to start doing in parallel things that should be sequential.. – Soonts Nov 16 '12 at 23:34