rust-lang / socket2

Advanced configuration options for sockets.

Home Page:https://docs.rs/socket2

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support `sockatmark()`-like functionality

leftmostcat opened this issue · comments

socket2 cannot currently handle the TCP urgent flag correctly according to specifications. Per https://www.rfc-editor.org/rfc/rfc1122#page-84 and https://www.rfc-editor.org/rfc/rfc6093#page-5, the intended standard method of handling the urgent flag in TCP is to notify the process out-of-band that there is an urgent mark, at which point the process moves into an "urgent mode" until reaching the urgent mark in-band. socket2 is currently missing the ability for the process to detect when it has reached the urgent mark.

While #296 suggests that polling is out-of-scope for socket2, this shouldn't be necessary for implementing this functionality. Using the POSIX socket API, a process can set SO_OOBINLINE as a socket option (to which set_out_of_band_inline() is equivalent) and use sockatmark() to detect when the urgent mark is reached, independent of polling mechanism.

The SIOCATMARK ioctl is the basis of sockatmark() and could be consumed by socket2 to provide this functionality. rust-lang/libc#3275 intends to expose this for Unix-like systems and it is exposed in the WinSock Rust crate. A synchronous function is_at_urgent_mark(&self) -> bool or similar would address this gap.

I think a wrapper around sockatmark should be fine.

Do you have any preference as far as naming? is_at_urgent_mark() seems clear and appropriate to me, but I'm open to another name.

Maybe is_at_out_of_band_mark or is_at_oob_mark? To match set_out_of_band_inline. But both are a little long, so I'm also ok with is_at_urgent_mark or even with is_at_mark.

I'd prefer not to call it anything involving urgent, since the mechanism is not specific to TCP sockets, and the most general name is just "the out-of-band mark". For instance, on Linux, Unix domain sockets of type SOCK_STREAM can similarly queue a single byte of out-of-band data, and the underlying code does not refer to an urgent pointer at all, apart from the naming of the SIGURG signal.

I'd prefer not to call it anything involving urgent, since the mechanism is not specific to TCP sockets, and the most general name is just "the out-of-band mark". For instance, on Linux, Unix domain sockets of type SOCK_STREAM can similarly queue a single byte of out-of-band data, and the underlying code does not refer to an urgent pointer at all, apart from the naming of the SIGURG signal.

OOB/out-of-band is fine with me.