Home/ Questions/Q 8842971
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T11:06:01+00:00

My app communicates with a server over TCP, using AsyncSocket. There are two situations

  • 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0