Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am reading the TCP PUSH section in the TCP/IP Guide, and have a question on this paragraph:

It's important to realize that the push function only forces immediate delivery of data. It does not change the fact that TCP provides no boundaries between data elements. It may seem that an application could send one record of data and then “push” it to the recipient; then send the second record and “push” that, and so on. However, the application cannot assume that because it sets the PSH bit for each piece of data it gives to TCP, that each piece of data will be in a single segment. It possible that the first “push” may contain data given to TCP earlier that wasn't yet transmitted, and it's also possible that two records “pushed” in this manner may end up in the same segment anyway.

My question is on the last sentence with italics, how can data be given to TCP earlier, with the PSH flag set, yet not be transmitted? Doesn't having the PSH flag set immediately flush the buffers right away?

share|improve this question
It doesn't say "given to TCP earlier with the push flag set" it just says "given to TCP earlier". For example, perhaps when you set nodelay on your TCP socket it flushes things out with a PSH on the next packet sent. There's nothing to stop you from sending some data, then setting nodelay, then sending more data, which will then get sent with the PSH flag, pushing the previous data in the buffer out with it. – Alastair Maw Sep 10 '14 at 16:07
up vote 2 down vote accepted

It is important to understand that TCP is a streaming protocol, and separation into segments is only an implementation detail and it is just because some lower level protocols are packet-based.

Setting PSH flag is only an indication to the receiving end that it should flush its buffer to the application. Due to the asynchronous nature of the TCP/IP stack, by the time the application is notified that there is data pending, several other, newer, packets might already have been received, and everything together will be sent to the application. TCP is a stream.

Moreover, be aware that there is no guarantee that separation into TCP segments will be preserved on the network too. It is true that usually it is preserved, but there are proxies, deep inspection firewalls, etc., which can actually glue several small segments into one bigger one, etc.

share|improve this answer

There are situations where TCP is not allowed to send any fresh data, and wait for ACKs first.

In general the PUSH flag forces TCP on the receiver to deliver its buffer contents to the application. It does not force the sender's TCP to send anything.

share|improve this answer
Actually, once the sender's TCP stack sees the push bit it should send all unsent data. – user26825 Dec 2 '11 at 5:30
@user26825 No, there are situations where TCP is not even allowed to send any fresh data, and wait for ACKs first. – artistoex Dec 2 '11 at 14:07
I see, as in the sliding window is full and so it waits for the acks before sending again. I think you should rephrase your answer though because it can get confused with "A sending TCP is allowed to collect data from the sending user and to send that data in segments at its own convenience, until the push function is signaled, then it must send all unsent data." from RFC 793. – user26825 Dec 2 '11 at 15:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .