0
votes

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?

1

1 Answers

1
votes

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.