One TCP question
Author
Hello to all.
I'm new to network programming and I would like to ask one simple question.
I have one client/server TCP/IP program. I'm currently sending to server 4K data packets.
What's happening if two or more 4K packets server gets at once?
Does I get a 8K data in one larger buffer?
I need to know that because I'm not sure if server is processing all data (because I have just one pointer to received buffer), or some data is lost (if two or more packets get stacked one upon another).
I don't know if this is a stupid question or not, I'm just new in this area of programing.
Thanx in advance
TCP is stream based and does not have an intrinsic concept of packets. To therefore if you send 4K over the line twice, you will see 8K on the receiving end.
it's been awhile so i may be off but i think it works like this:
a) process/thread 1 writes X bytes of data
b) process/thread 2 calls read with a size limit, lets say it's 2X
- it might get < X, in this case it must call read again to get the rest
- it might get > X, in this case it must break up the data on it's own
the client/server have to agree on what is being communicated (this is called a protocol). for example maybe the server is waiting for a certain byte sequence to know it had a complete message (i.e. '__END__' or whatever) or maybe it knows to expect a certain number of total bytes.
just because you write X bytes at a time doesn't when that X bytes will be read with each call to read.
a) process/thread 1 writes X bytes of data
b) process/thread 2 calls read with a size limit, lets say it's 2X
- it might get < X, in this case it must call read again to get the rest
- it might get > X, in this case it must break up the data on it's own
the client/server have to agree on what is being communicated (this is called a protocol). for example maybe the server is waiting for a certain byte sequence to know it had a complete message (i.e. '__END__' or whatever) or maybe it knows to expect a certain number of total bytes.
just because you write X bytes at a time doesn't when that X bytes will be read with each call to read.
The kernel (or network stack) buffers received data until you decide to read it out with a call to recv() or similar.
if the data stacks over and over the internal kernel buffers would be overflowed and you will have packet lost!
Quote:Original post by rzcodeman
if the data stacks over and over the internal kernel buffers would be overflowed and you will have packet lost!
Not exactly. The receiving TCP stack maintains a buffer ("window") that is filled with data received from the remote endpoint. When a packet is received, the window size is decreased by the amount of data received and that new remaining size is sent to the remote side along with the ACK. When the remaining buffer is zero, the remote stops sending data. When data is read from the local buffer with a call to read() or recv(), the window size increases again and is sent to the remote which will resume sending the remaining data.
The only way that actual data loss can occur is that one side decides to time out or drops the connection for another reason, which will be signalled to both involved sockets, so an error condition is recognized correctly in most cases.
Messages in a TCP stream can get joined together OR broken up. You shouldn't assume that they will arrive in any other fashion.
Specifically, a "chunk" read by recv(), might contain part of one message and part of the next. It might contain two complete messages. It might contain just one byte. You can't know what's going to happen, and have to handle every eventuality.
Mark
Specifically, a "chunk" read by recv(), might contain part of one message and part of the next. It might contain two complete messages. It might contain just one byte. You can't know what's going to happen, and have to handle every eventuality.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
