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

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

    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