Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sockatmark()-like functionality #450

Open
leftmostcat opened this issue Jun 16, 2023 · 5 comments
Open

Support sockatmark()-like functionality #450

leftmostcat opened this issue Jun 16, 2023 · 5 comments

Comments

@leftmostcat
Copy link

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.

@Thomasdezeeuw
Copy link
Collaborator

I think a wrapper around sockatmark should be fine.

@leftmostcat
Copy link
Author

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.

@Thomasdezeeuw
Copy link
Collaborator

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.

@LegionMammal978
Copy link

LegionMammal978 commented Oct 8, 2023

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.

@Thomasdezeeuw
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants