I did a bit of digging and found this from our fellow on the list:
collaboration.opengroup.org/tech/austin/plato/mailarch.php?soph=N&action=show&archive=austin-group-l&num=31107&limit=100&offset=0&sid=66b57aa7ddd00
________________________________________
发件人: Niu Danny <danny...@hotmail.com>
发送时间: 2024年8月9日 10:09
收件人: Philip Guenther
抄送: Austin Group Mailing List
主题: 回复: <poll.h>: can some POLL* values be marked obsolescent?
learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll#remarks
(retrieved 2024-08-09 UTC+8)
The tables in "Remarks" section lists cases of *BAND and OOB. It also mentions
POLLPRI as: "This flag is not supported by the Microsoft Winsock provider"
learn.microsoft.com/en-us/windows/win32/winsock/protocol-independent-out-of-band-data-2
(retrieved 2024-08-09 UTC+8)
is a general discussion of OOB in all protocols in Windows that supports OOB,
and there is a section in it dedicated to TCP.
The person who told me that OOB/URG is for dealing with head-of-line blocking
and raised the opinion that it's implementation defined and not portable is on
this list. It was a distant discussion, and I'm not sure if I can find link to
the original mail.
Of course, POSIX don't have to follow Windows. I just thought if there's a
well-documented existing implementation, we can reference that.
________________________________________
发件人: Philip Guenther <guent...@gmail.com>
发送时间: 2024年8月3日 14:24
收件人: Niu Danny
抄送: Austin Group Mailing List
主题: Re: <poll.h>: can some POLL* values be marked obsolescent?
On Fri, Aug 2, 2024 at 10:57 PM Niu Danny <danny...@hotmail.com> wrote:
> BAND data corresponds to out-of-band data bit mask for
> flags in `recv` and `send` calls, which in turn corresponds
> to TCP Urgent packet bit,
On what OS and where is that documented?
> and it's a (legacy) mechanism
> for dealing with head-of-line blocking. It's used by Telnet
> and FTP but not HTTP.
Where is that specified? It sure looks to me that TCP OOB data
matches the semantics in previous POSIX specs for the 'high-priority'
data checked for with POLLPRI. (At most one high-priority data was
permitted, and it was not subject to queuing/backpressure like the
priority bands)
That's how URG 'data' is reported on OpenBSD and is what is documented
by the Linux manual project at
https://man7.org/linux/man-pages/man2/poll.2.html
Indeed, that page currently documents that the values I suggest be
deprecated "convey no further information" on Linux.
> Windows has fully specifies behavior regarding TCP URG bit,
> OOB, and its own WSAPoll, which is a distant relative of ours.
I can believe that. Can you point us to the part of those docs which
you feel are relevant? What POLL* constant (or WSAPoll equivalent) do
they use for reporting not-yet-reached TCP URG pointer?
> Someone previously voiced their opinion that, since OOB is
> specified as protocol-specific by POSIX, OOB and band data
> cannot be portably used. Nonetheless, I believe the standard
> should note its history, and recommend developers to consult
> implementations' documents, as well as IETF RFCs if they
> insist on using it.
Last I checked, no IETF RFC provides any indication about poll() POLL*
values to use. Do you know of one that does?
I was careful in my request to suggest deprecation of the 'BAND' and
'NORM' values and *not* POLLPRI.
Philip Guenther
