Re: poll(): IN/OUT vs {RD,WR}NORM

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

    Date:        Tue, 28 May 2024 22:46:09 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202405290246.WAA17003%Stone.Rodents-Montreal.ORG@localhost>

  | I question whether it actually works except by accident; see RFC 6093.

I hadn't seen that one before, I stopped seriously following the IETF
around the end of the last millennium, it was becoming way too commercially
based (decisions no longer based purely on technical merit) with way way
too much bureaucracy.

Aside from the middlebox problem (of which I wasn't aware -- and IMO
anything in the middle of the internet which touches anything above the
IP layer is simply broken - I know NAT forces force a little of that,
but NAT is also simply broken) there is nothing new in there, except
that their change from the Hosts Requirement solution for the off-by-one
issue was the wrong way to go.   The HR group discussed that at length,
using the "last byte of the urgent data" is safe, using that + 1 is not,
in that a system receiving urgent data which believes it should be +0
will be waiting for one more byte to arrive, which might never be sent,
if the transmitter is using +1.   On the other hand, if the transmitter
uses +0 and the receiver is expecting it to be +1, all that happens is
that the U bit turns off one byte sooner, all the urgent data is still
there and available to be read (of course, if anything is pretending this
is one byte of out of bound data they fail either way - but that, as that RFC
says, is simply broken).   (The uninteresting cases when both sender and
transmitter use the same concept aren't worthy of mention).

Of course, if essentially the whole internet has settled on the +1 version
(the original specification, instead of the example code) then perhaps
that change may have been warranted - I certainly haven't surveyed anything
to see which way various systems actually do it, and I expect a lot of
the original systems are long gone by now.

  | But only a few implementors paid any attention, it appears.

Does the BSD stack not do this the way that HR defined things?   I thought
that was changed way way back, before CSRG stopped generating the code.

  | But the facility it provides is of little-to-no use.  I can't recall
  | anything other than TELNET that actually uses it,

TELNET and those protocols based upon it (SMTP and FTP command at least).
SMTP has no actual use for urgent data, and never sends any, but FTP can
in some circumstances I believe (very ancient unreliable memory).

  | Furthermore, given that probably the most popular API to TCP, sockets,
  | botched it by trying to turn it into an out-of-band data stream,

Yes, that was broken.

  | then botched it further by pointing the urgent sequence number to
  | the wrong place,

In fairness, when that was done, it wasn't clear it was wrong - that
all long predated anyone even being aware that there were two different
meanings in the TCP spec, people just used whichever of them was most
convenient (in terms of how it was expressed, not which is easier to
implement) and ignored the other completely.   That's why it took
decades to get fixed - no-one knew that the spec was broken for a long
time.

Further, if used properly, it really doesn't matter much, the application
is intended to recognise the urgent data by its content in the data stream,
all the U bit (& urgent pointer) should be doing is giving it a boot up
the read stream to suggest that it should consume more quickly than it
otherwise would.  Whether than indication stops one byte earlier or later
should not really matter.

The text in that RFC about multiple urgent sequences also misses that I
think - all that matters is that as long as there is urgent data coming,
the application should be aware of that and modify its behaviour to read
more rapidly than it otherwise might (if it never delays reading from the
network, always receives & processes packets as soon as they arrive, which
for example, systems which do remote end echo need to do) then it doesn't
need to pay attention to the U bit at all).

If there are multiple sequences that demand speedy processing, each should
be processed when it is encountered, and if that affects what is done
with other, "normal" data that is also being read quickly, that's just an
aspect of the application protocol.

kre

ps: I am not suggesting that anyone go design new protocols to use urgent
data, just that the system isn't nearly as broken as some people like to
claim.