search

wahern / cqueues

Continuation Queues: Embeddable asynchronous networking, threading, and notification framework for Lua on Unix.
http://25thandclement.com/~william/projects/cqueues.html
MIT License
250 stars 37 forks source link

Support "urgent" packets #11

Open daurnimator opened 10 years ago

daurnimator commented 10 years ago

From https://github.com/wahern/cqueues/issues/5

I do need to add proper :recvmsg and :sendmsg calls which allow reading and sending OOB data, support SO_OOBINLINE as a socket option, etc. It's just not a high-priority at the moment. It will require careful testing across all the platforms.

I added the mask because the assignment is a signed, narrowing conversion (.events is a short) and I was just trying to be conscientious about undefined behavior. I only included POLLIN and POLLOUT in the mask because those are the only events currently supported. I could have made the mask 0x7fff but figured it was more prudent to filter out values which previously wouldn't have been seen.

The code has to translate POLLIN and POLLOUT to the subsystem-specific flag. For Linux it's easy because POLLIN, POLLOUT, and POLLPRI are identical to EPOLLIN, EPOLLOUT, and EPOLLPRI. I think Solaris just reuses POLLIN directly.

However, for kqueue I haven't researched the issue. Some quick Googling turned up EV_OOBAND, but it's not documented in the OS X man page, and it doesn't even exist on OpenBSD.

The only application I know of off-hand that uses OOB data is telnet. FWIW, a grep through the PostgreSQL sources, for example, doesn't turn up any matches for "POLLPRI" or "MSG_OOB".

daurnimator commented 9 years ago

Interesting tangentially related article: https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html

wahern commented 9 years ago

On Wed, Apr 08, 2015 at 07:15:02PM -0700, daurnimator wrote:

Interesting tangentially related article: https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html

I've long thought about making SO_OOBINLINE the default, precisely out of concern about this issue. But what little research I did suggested that it wasn't an issue. I don't remember which systems I ran my sample programs on, but I probably should have been more rigorous about it.

daurnimator commented 9 years ago

quick Googling turned up EV_OOBAND, but it's not documented in the OS X man page, and it doesn't even exist on OpenBSD.

More info on EV_OOBAND from apple header:

 * On input, EV_OOBAND specifies that only OOB data should be looked for.
 * The returned data count is the number of bytes beyond the current OOB marker.
 *
 * On output, EV_OOBAND indicates that OOB data is present
 * If it was not specified as an input parameter, then the data count is the
 * number of bytes before the current OOB marker. If at the marker, the
 * data count indicates the number of bytes available after it.  In either
 * case, it's the amount of data one could expect to receive next.

I found this code inside boost:

// Older versions of Mac OS X may not define EV_OOBAND.
#if !defined(EV_OOBAND)
# define EV_OOBAND EV_FLAG1
#endif // !defined(EV_OOBAND)
daurnimator commented 9 years ago

I made an initial pass with https://github.com/daurnimator/cqueues/commit/52baaf1c25bc7e6f7cb4685cb05f4ed47a3f404a

I've only tested on linux; the BSDs in particular probably need work.