4 ms·
The urgent pointer mechanism is not reliable or well-implemented enough for widespread use. Excerpts from RFC 6093 (from 2011, https://tools.ietf.org/html/rfc6
by tonyg 8y ago
The urgent pointer mechanism is not reliable or well-implemented enough for widespread use.
Excerpts from RFC 6093 (from 2011, https://tools.ietf.org/html/rfc6093 https://tools.ietf.org/html/rfc6093), "On the Implementation of the TCP Urgent Mechanism", which examines current implementation practices in detail, and ultimately "recommends against the use of urgent indications":
Unfortunately, virtually all TCP implementations process TCP urgent
indications differently. (sec. 3.1)
All the popular implementations [...] interpret the semantics of the
TCP Urgent Pointer as specified in Section 3.1 of RFC 793. This means
that even when RFC 1122 formally updated RFC 793 to clarify the ambiguity
[...] this clarification was never reflected in actual implementations
(sec 3.2)
Because implementations just never bothered to implement RFCs 1011 and 1122's update, later in the document they retract the advice given by RFCs 1011 and 1122, overriding the earlier overriding of RFC 793, effectively returning to RFC 793's definition for the urgent pointer! (!)
There's more:
[...] an application might be unable to interoperate with itself if both
the TCP sender and the TCP receiver are running on the same host. (sec 3.2)
[S]ome middleboxes clear the urgent indications by clearing the URG
flag and setting the Urgent Pointer to zero. (sec 3.4)
Ultimately: don't do it. You will not have a fun time.
As a result of the issues discussed in Section 3.2 and Section 3.4,
new applications SHOULD NOT employ the TCP urgent mechanism. (sec 5)
Additionally, applications that still decide to use the urgent
mechanism need to be designed for correct operation even when the URG
flag is cleared by middleboxes. (sec 6)
- tonyg 8y agoIt's a bit sad that, as a result of the urgent pointer being useless, there are 16 zero bits sent in every TCP header. They can't even be repurposed - the specs say they're meaningful only when the URG bit is set, and leave their condition when URG is clear unspecified, but various middleboxes take a clear URG bit as licence to explicitly zero the urgent pointer on the way through. (And of course some clear it no matter what.) This is one of those areas where IPv6 could have been something quite different and amazing. Separating TCP and IP was, in hindsight, a mistake; some alternate universe out there had the IPv6 process focus on finding a better way of carving up the problem.
- AndyMcConachie 8y agoPeople use TCP for all kinds of things. You have no way of knowing if some application developer out there who can design both sides of a connection(client/server) has not made good use of URG.
- twic 8y agoThe idea in the article was to assign entirely new semantics to the fields involved in the urgent mechanism, so the brokenness of existing endpoint implementations doesn't matter. Broken middlebox implementations, however, are one of the several reasons why this idea is useless.
- tonyg 8y agoI didn't get that from the article: I understood the idea to be to use the existing implementations of the urgent pointer, in context of the BSDish socket APIs we have, as message boundary markers. And, if that is done, we end up in the mess that RFC 6093 clearly describes.