socket programming: How do I handle out of band data

Question

I just looked into wikipedia's entry on out-of-band data and as far as I understand, OOB data is somehow flagged more important and treated as ordinary data, but transmitted in a seperate stream, which profoundly confuses me.

The actual question would be (besides "Could someone explain what OOB data is?"):

I'm writing a unix application that uses sockets and need to make use of select() and was wondering what to do with the exceptfds parameter? Do I need to put all my sockets into this parameter and react to such events? Or do I just ignore them?

Hendeca

Answer 1

I know you've decided you don't need to handle OOB data, but here are some things to keep in mind if you ever do care about OOB...

• IPv4 doesn't really send OOB data on a separate channel, or at a different priority. It is just a flag on the packet.
• OOB data is extremely limited -- 1 byte!
• OOB data can be received either inline or separately depending on socket options
• An "exception" signaling OOB data may occur even if the next read doesn't contain the OOB data (the network stack on the sender may flag any already queued data, so the other side will know there's OOB ASAP). This is often handled by entering a "drain" loop where you discard data until the actual OOB data is available.

If this seems a bit confusing and worthless, that's because it mostly is. There are good reasons to use OOB, but it's rare. One example is FTP, where the user may be in the middle of a large transfer but decide to abort. The abort is sent as OOB data. At that point the server and client just eat any further "normal" data to drain anything that's still in transit. If the abort were handled inline with the data then all the outstanding traffic would have to be processed, only to be dumped.

It's good to be aware that OOB exists and the basics of how it works, just in case you ever do need it. But don't bother learning it inside-out unless you're just curious. Chances are decent you may never use it.

Fiddler

So if I get this right, the perfect use for OOB data is in any binary stream - like the file transmission example given, or an audio/video stream, etc. – Hendeca

Binary or text, doesn't matter. But binary files do tend to be larger, resulting in fuller queues & packets in transit. Use OOB when you want to signal some exceptional event and you don't want to process any data already queued or in flight. – Fiddler

I found this article pretty interesting: serverframework.com/asynchronousevents/2011/10/… – Hasseman

Answer 2

I think I found the answer on this page. In short:

I don't need to handle OOB data on the receiving side if I'm not sending any OOB data. I had thought that OOB data could be generated by the OS of the sender.

Hendeca

Yes, if it's not sent you don't need to handle it. – Fiddler

@Hendeca care to explain more? The original link is broken now. – Persistent

@Hendeca Thanks for the reply (SO is amazing that you can get a reply 10 years after the answer!) I looked at the page and tried to find info on why one doesn't need to handle OOB if it's not sending OOB. I must be missing something. It seems the page shows an example of the server sending OOB while the client receiving OOB? – Persistent

@PengheGeng Because by default the data is not flagged as OOB data. Check book APUE Chapter 16.7 if you are still interested. – Aborning

Answer 3

You don't need to handle it at the receiving end even if you are sending it - OOB data is transparently ignored in all circumstances unless you actively go about receiving it.

Weaks