0

I'm writing an iOS application that handles a lot of TCP traffic (over WiFi).

Here's my scenario, all writes/reads are done on the dispatch queue QOS_CLASS_UTILITY.

  1. Send request for data packet (~20 bytes)
  2. Receive data packet (~100-64k bytes), parse data, send 1. again
  3. When user presses widget on the screen start sending bytes each 16ms (~20 bytes each packet)

The 1. and 2. works fine because they are chained (packets: 1, 2, 1, ...). However when user presses the widget on the screen things get messy. Looks like something blocks the connection and I don't read all the packets.

I have tried various approaches (different dispatch queues, checked if stream has enough bytes available and so on).

I know that the TCP is full-duplex and asynchronous reads/writes shouldn't be a problem, but after debugging this stuff for a week I'm out of ideas what can be wrong.

Tomasz Wójcik
  • 955
  • 10
  • 23
  • You need to show some code. Are you sure you are using TCP not UDP. TCP shouldn't lose data except with extremely poor connectivity (and then it will drop the connection rather that miss data from the middle of the stream) as it is a reliable transport – Paulw11 Jun 16 '15 at 11:10
  • I see you refer to NSStream, so you are using TCP, but you still need to describe your problem more clearly. What do you mean you "don't read all packets". TCP is stream oriented, not datagram oriented like UDP so just because you write 20 bytes doesn't mean 20 bytes will be received at the other end- the other end may receive 80 bytes (4 20 byte "packets" sent together) or 10 bytes followed by 70 bytes. How are you parsing the input stream? – Paulw11 Jun 16 '15 at 11:14
  • Yes, I'm sure that I use TCP. Sadly I cannot share the codes.After I receive a packet I copy it's bytes to NSData, then pass the copied data to the parser and parse it on another thread. It feels that ansychronous reads and writes collide and then mess happens (that's my wild guess with losing packets. I'm not 100% sure about this). – Tomasz Wójcik Jun 16 '15 at 11:18
  • You can't lose packets with TCP, or if you do it will be just before the whole connection fails. It is hard to help you if you can't show any code, but if I were you I would look closely at where you read the data. Do your 20 byte packets have start/header bytes that allow you to correctly determine where a packet starts. You may send 20 bytes but your call to `read` may return only 16 with the next 4 bytes in the next call to read, or you may send 20 bytes and another 20 bytes 16ms later with all 40 bytes returned in a single read – Paulw11 Jun 16 '15 at 11:22
  • Excatly like you said, I have packets with headers containing information how many bytes the packet contains. I read the bytes from the stream to the buffer, check for headers, create packets. So I have a multipart packet handled. The problem appear when user interaction occurs, which sends extra packets every 16ms. I was also thinking that the NSStream/socket throughput can be a problem. PS. I have followed the Apple's guides to stream sockets when implementing my solution. – Tomasz Wójcik Jun 16 '15 at 11:31
  • If you are confident that your parsing is correct then you may have an issue with multi-threading – Paulw11 Jun 16 '15 at 11:38
  • I already tried synchronization, same and different dispatch queues for reads and writes. Any other ideas? Remember that the problem happens when I spam writes every 16ms. Output stream always have the space available. – Tomasz Wójcik Jun 16 '15 at 11:46
  • It sounds like you are assembling data out of order or something like that. You could try a serial dispatch queue, but without code I can't really say – Paulw11 Jun 16 '15 at 11:50
  • I'm decoding a video, the frames look good until I start spamming that 16ms requests. To complicate it even more it doesn't mess the picture for every 16ms packet, but sometimes it happens after 200ms, other times after 3000ms. And that 16ms packets doesn't request any response from the server, so when the image is decoded I simply request another one. – Tomasz Wójcik Jun 16 '15 at 11:55

0 Answers0