0

While using a TCP based connection if I send some data to a client but because of lag or some reason the client do not reads the data. Will the data merge (Socket.Avalialbe = previous request + new request) and Socket.Recieves both buffers combined or will I need to call Soocket.Receive twice to receive the data in order that I sent it in?

KidCoder
  • 25
  • 6
  • Socket technology works on SYN/ACK. Meaning every packet requests confirmation of receipt, and if the confirmation fails or times out, the packet is typically sent again up to X number of retries before cancelling. You can read some information [here](http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml) – Kraang Prime Jan 05 '17 at 19:43

1 Answers1

0

It is possible that in one 'recv' you will get all the bytes that were sent across with two 'sends'.

TCP does not maintain message boundaries. It's upto the application to make sense of the data. You cannot assume that one 'send' will result in one 'recv'. Bytes received will be in TCP's buffer until application calls 'recv'.

Prabhu
  • 3,443
  • 15
  • 26
  • Only a hint. If you send large blocks of data, it is also possible, that 'recv' only gets the first part and you need a second 'recv' to get the remaining. – H.G. Sandhagen Jan 05 '17 at 19:57
  • @H.G.Sandhagen that will only happen if the client is not having a fast enough connection to receive the entire buffer at once right? – KidCoder Jan 05 '17 at 20:08
  • That also means that if each buffer I sent has a special purpose then I should include the length of the data at the begging of the buffer to make sure that I received the whole data? Or is there any other way around it? – KidCoder Jan 05 '17 at 20:11
  • Yes but it will be not enough. When you send binary data, how to be sure the the bytes you read are the length of a block? Depending on the data and how robust the communication should be, you may also and some bytes as an header to recognize the start of a new block and make sure that this byte combination does not occour in your normal data. – H.G. Sandhagen Jan 05 '17 at 21:03
  • @KidCoder : As an answer to your second comment: Yes, prepending the data with the data length is the best way to go. This is called _Length-prefixing_ (or _Length prefixing_) and I've described how it is done in [**one of my previous answers**](http://stackoverflow.com/a/37352525/3740093). – Visual Vincent Jan 05 '17 at 23:04
  • @H.G.Sandhagen can't I just calculate the length of the data to determine the end of one request so that the next byte will automatically become start of a new one? The first byte I am sending is the header which tells me what to actually do with the data. And another problem is to make sure that the combination do not occurs in the data. All values are dynamic and thus I can't guarantee that they won't clash – KidCoder Jan 06 '17 at 10:53
  • @VisualVincent the current format I am sending data in quite similar to yours. The only different is that that first byte is the header and then the next 4 bytes are the length. Is is better to have the header first? – KidCoder Jan 06 '17 at 10:54
  • @KidCoder : Where you place the header doesn't matter as long as you read it correctly. Both ways work fine. -- As for the comment you wrote to H.G.Sandhagen the answer is: Yes. You can use length-prefixing without a problem. He even mentioned it in the end of his comment: `you may also and some bytes as an header to recognize the start of a new block`. – Visual Vincent Jan 06 '17 at 12:03
  • @KidCoder : `And another problem is to make sure that the combination do not occurs in the data.` - It doesn't matter if something that looks like a header is added to the data as long as you read each packet by it's length header. You know where the packet ends because you know because you know when to stop reading it. If you have implemented length-prefixing properly there are no problems you have to be concerned about. You just read and stop reading data, and that's it. – Visual Vincent Jan 06 '17 at 12:07
  • So he was indirectly, basically saying the same thing (length prefixing). Thanks for clearing things out @VisualVincent! – KidCoder Jan 06 '17 at 12:17
  • @KidCoder : No problem. – Visual Vincent Jan 06 '17 at 12:25