I have no interest in deprecating MSG_OOB.
Hat tip to Microsoft for the quality of the their docs on this...but
WSAPoll != poll and code that aims to operate with both POSIX and
WinSock is already absolutely full of remapping of names, types, and
features to make some sort of base source work with both.
So, I'll amend my original proposla to explicitly take into account MSG_OOB:
IMHO, if the POSIX certified OSes and "basically POSIX, with some
stuff missing or mismatched" OSes have a consensus on MSG_OOB data
being reported with POLLPRI, then POSIX should deprecate POLLRDNORM,
POLLRDBAND, POLLWRNORM, and POLLWRBAND.
Philip
On Thu, Aug 8, 2024 at 7:12 PM Niu Danny <danny...@hotmail.com> wrote:
>
> 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
