On Mon, 21 Apr 2008 21:19:33 BST Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > But in any case setting PSH on a
> > packet with no data serves no real purpose.
>
> i think that's incorrect: it ensures a push of any data that is already buffe
> red but un-pushed
> (ie, the immediately preceding segment had no PSH, and the receiver's impleme
> ntation buffers
> accordingly).
Other major implementations don't set PSH on a pkt with no
data so clearly they don't agree with you. Here's why:
According to rfc1122 page 83,
The PSH bit is not a record marker and is independent of
segment boundaries. The transmitter SHOULD collapse
successive PSH bits when it packetizes data, to send the
largest possible segment.
A TCP MAY implement PUSH flags on SEND calls. If PUSH
flags are not implemented, then the sending TCP: (1)
must not buffer data indefinitely, and (2) MUST set the
PSH bit in the last buffered segment (i.e., when there
is no more queued data to be sent).
The implication is that the "preceding segment" to a pkt with
no data *will have* PSH set.
> part of the problem with the continued specification of protocols, even 30
> years on, as `formal' english text is that it can appear to be ambiguous when
> it's just subtly precise. that's why i had to say `i think' as opposed to QED
Indeed. One point to note is that RFCs (at least used to)
document existing implementations but some times not
everything is documented clearly and precisely. Unlike
programming language implementations where things left
undefined by the specification can be implemented however you
wish, here you have to be compatible with existing
implementations as far as possible (in order to maximize
interoperability).
