0

I got a problem when using NSInputStream. I have client app which connect to a server then server will start to send message to my client app through TCP repeatedly about 1 message per second. Server is just broadcasting message to client and message is xml format. The server send a message as one packet.

Now the problem is that when I read byte from NSInputStream the data got truncated which mean instead of receive 1 complete message, I got 2 separate data(partial xml) respond from time to time. I am not able to debug because it already happen when I read data byte from NSInputStream.

I use Wireshark to analyse every packet I receive and when it happen data got truncated too, because TCP so partial data retransmit to my client. I have tried to log every partial data byte, the sum of partial data always around 1600 byte.

I have no idea how did they design and implement server side, but I do know there are many of people connect to that server and continuous get broadcasting message from it.

Does anyone encounter this problem? Can anyone help? Is it possible that data is over the max size and get splited?

NelsonPunch
  • 87
  • 6

1 Answers1

1

This is not a problem per se. It is part of the design of TCP and also of NSInputStream. You may receive partial messages. It's your job to deal with that fact, wait until you receive a full message, and then process the completed message.

1600 bytes is a little strange. I would expect 1500 bytes, since that's the largest legal Ethernet packet (or especially somewhere around 1472, which is a really common MTU, minus some for the headers). Or I might expect a multiple of 1k or 4k due to buffering in NSInputStream. But none of that matters. You have to deal with the fact that you will not get messages necessarily at their boundaries.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Well. yes I have to wait until every part of data arrived and combine them to become one complete data and I am doing that way now, but It also lead to another problem in client app, app has a count down timer and time is depend on the data from server, If I wait for every part of data it cause count down timer not smooth. – NelsonPunch Jan 11 '13 at 00:49
  • I guess server was implemented with Java, another group of people work on Android app does not encounter this kind of problem. If TCP auto split data when sender send data out would it be auto reconstruct on receiver side? – NelsonPunch Jan 11 '13 at 00:59
  • Yes, TCP will automatically reassemble the data, even if packets are dropped and resent, and even if packets come out of order (which happens). You can't expect packets to come to you at a constant rate on a busy network. The Java libraries may be buffering for you differently than the iOS libraries, but being in Java will not make network packets arrive consistently at the network interface. – Rob Napier Jan 11 '13 at 01:36
  • What if server's sending buffer overflow will it cause this kind of problem? That server is consumed by many user perhaps more than 50 at same time. – NelsonPunch Jan 11 '13 at 07:46
  • 50 isn't very many users for a well-designed server, but yes, your server could be less consistent in how it sends you packets if it's talking to a lot of folks at the same time. The network card can only send one packet at a time, so it may send one to you and then send some to other people and then get back around to you. This isn't an overflow, and nothing you've said suggests you're dropping packets or anything. You just can't rely on getting packets at even intervals on an Ethernet- or 802.11-based system (vs Token Ring or ATM which can give you that). – Rob Napier Jan 11 '13 at 14:47
  • OK, here is result I test recently. on simulator if I use wifi for internet connection this problem appear. If I use enthernet cable as internet connection this problem never appeared. Any idea? thats why this problem appear when running on physical device because device use wifi as internet connection not enthernet cable. – NelsonPunch Jan 15 '13 at 07:21
  • This isn't surprising. Different network can certainly have different MTUs and can certainly fragment differently. You cannot rely on most network transports handing you packets in a reliable order at consistent intervals with predictable fragmentation. It is not something most modern network transports promise. If you have an application that requires it, you would have to change your network transport to something like ATM or Token Ring that can promise these things. That means replacing the network hardware throughout the network. You must adapt your code to how networks work. – Rob Napier Jan 15 '13 at 14:41
  • Ya, you are right. It looks like they send all data in one packet, which is exceed MTU so it got fragmented. Although, I haven't solve problem yet, but thank you for helping me to locate the issue so I mark your answer as correct one. – NelsonPunch Jan 16 '13 at 00:58