Date: Tue, 28 May 2024 22:46:09 -0400 (EDT) From: Mouse <mo...@rodents-montreal.org> Message-ID: <202405290246.waa17...@stone.rodents-montreal.org>
| 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.