Re: kern/54435 (reading TCP urgent data with MSG_OOB doesn't clear poll(2) status)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/54435; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Chuck Silvers <chuq%chuq.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        Valery Ushakov <uwe%stderr.spb.ru@localhost>,
        Taylor R Campbell <riastradh%NetBSD.org@localhost>,
        Michael van Elst <mlelstv%serpens.de@localhost>,
        Christos Zoulas <christos%zoulas.com@localhost>,
        Rin Okuyama <rokuyama.rk%gmail.com@localhost>, matthew green <mrg%eterna.com.au@localhost>
Subject: Re: kern/54435 (reading TCP urgent data with MSG_OOB doesn't clear poll(2) status)
Date: Fri, 20 Nov 2020 03:31:11 +0700

     Date:        Thu, 19 Nov 2020 10:40:44 -0800
     From:        Chuck Silvers <chuq%chuq.com@localhost>
     Message-ID:  <20201119184044.GA24468%spathi.chuq.com@localhost>
 
 
   | The netbsd HEAD result is clearly wrong, since we never see "at mark",
   | and the mark should actually occur in between the two bytes returned by
   | the second recv(), so returning those two bytes together is also wrong.
 
 That latter is not correct.   If both bytes are there, they can both be
 returned.  The urgent pointer is not some kind of record marker.
 
 Once again, there is *no* out of band data in TCP, all data is (are)
 just data.
 
 All we have is an out of band "something urgent follows" single bit
 (actually a pointer that indicates somewhere in the window which is
 beyond where the "urgent" data was written, but the API offers just
 an "urgent data coming" single bit.)
 
 To use this, the application protocol needs to mark the data somehow
 (in band) to let the application determine what is what, the urgent
 pointer simply cannot achieve that.  Attempts to make it do so will
 simply lead to frustration.
 
 The rlogin "protocol" is a mess.   It isn't an example of anything
 useful, for anyone who wants to see uses of urgent data in TCP, look
 at telnet - there it is all done properly, and simply works.
 
 This is not a comment about your patch, and certainly restoring binary
 compat so old binaries work on new kernels is a very good thing (even
 when the old binary is rlogin).
 
 kre