   How do TCP Packets get merged?
  Hi :D, I was told tcp packets get merged when sent [VB.NET]. I would like to know exactly how this happens as I dont see how this can happen when you are sending an array of bytes. If so - then how can i seperate merged packets or prevent this from happening?Thanks :)Q   
  TCP is a stream protocol - it has no concept of packets, just a continuous stream of bytes. What you push out as one send may arrive as many tiny receives or anything in between.If you want discrete packets of information then you'll have to send some kind of delimiters along with your data (such as putting the data length as the first thing in every packet so you know how much to read).Also see question 14 of the forum faq.   ;  Thanks. That explains it.   ;  there is no concept of "packets" when you're dealing with TCP, which is stream-based protocol. Think of it like a file. If you do this with a file (pseudocode):fp = open("C:\Temp\Blah");write(fp, "the quick brown fox jumped over the lazy dog");write(fp, "hello world");write(fp, "this is a test");close(fp)When you then come back later, and go to read the data back, how do you "know" where one call stopped writing and other one began? You don't.If you want to separate the stream into distinct packets, you typically structure your packets so that they have a fixed-size "header" which contains the length of the rest of the data.   ;  Thanks codeka. I think I understand now.   ;Quote:Original post by quddusaliquddusHi :D, I was told tcp packets get merged when sent [VB.NET].  If so - then how can i seperate merged packets or prevent this from happening?You wouldn't want to if you could, other than to flush the socket at opportune times.  Sockets have enough error handling involved that you don't want to make it more complex than it needs to be, leave the OS well enough alone.Marquita Jensen   ;  http://en.wikipedia.org/wiki/Nagle's_algorithm   ;  There must be some 'concept' of packets  -- that they exist and can cause delays/problems when blocks of data which are sent together (bigger than MTU) dont all yet arrive or the entire connection gets delayed.The application might process a stream but what comes out of the stream has to be complete (to be used) and even if the process/thread/fiber blocks waiting for retransmits/whatever the application may have to be able to decide a contingency when it takes too long.   Application level throttling is often needed across internet connections because of various problems that happen in the real world. The concept of packets (as in  their atomic maximum size) is needed to decidehow data may need to be broken up to be able to compensate for the various problems.   ;  In my experience I've never found such low-level considerations useful for TCP, and far more often than not the concept of packets just gives people new to networking incorrect assumptions about how TCP will behave. Things like the MTU quickly become irrelevant as the networking stack knows about them and takes them into account when putting your large lump of data onto the wire. And how it's split up at the transport level doesn't make any difference to how you handle it at the receiving end, where you have little choice - if you want your code to work properly, all the time - except to continue buffering until you receive your entire message, just as you would with any other data stream such as a file.   