From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 21 Apr 2008 21:19:33 BST." <49bcef4f0acf09bf86e042eeff8ed42b@terzarima.net> From: Bakul Shah Date: Mon, 21 Apr 2008 14:06:27 -0700 Message-Id: <20080421210627.D6D915B66@mail.bitblocks.com> Subject: Re: [9fans] telnet vs. godaddy whois Topicbox-Message-UUID: 96d68676-ead3-11e9-9d60-3106f5b1d025 On Mon, 21 Apr 2008 21:19:33 BST Charles Forsyth 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).