socket's SO_OOBINLINE option does not work

[giampaolo]

BPO	3278
Nosy	@gpshead, @giampaolo

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/gpshead'
closed_at = <Date 2008-07-06.19:36:00.591>
created_at = <Date 2008-07-04.02:18:00.795>
labels = ['invalid', 'type-bug', 'library']
title = "socket's SO_OOBINLINE option does not work"
updated_at = <Date 2008-07-06.19:36:00.590>
user = 'https://github.com/giampaolo'

bugs.python.org fields:

activity = <Date 2008-07-06.19:36:00.590>
actor = 'gregory.p.smith'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2008-07-06.19:36:00.591>
closer = 'gregory.p.smith'
components = ['Library (Lib)']
creation = <Date 2008-07-04.02:18:00.795>
creator = 'giampaolo.rodola'
dependencies = []
files = []
hgrepos = []
issue_num = 3278
keywords = []
message_count = 6.0
messages = ['69237', '69238', '69343', '69350', '69352', '69353']
nosy_count = 2.0
nosy_names = ['gregory.p.smith', 'giampaolo.rodola']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3278'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']

[giampaolo]

When the SO_OOBINLINE option is used against a socket, out-of-band data
should be placed in the normal data input stream as it is received.
In fact this is what happens on Windows and Linux by using the script below.
On FreeBSD this does not happen. select instead of returning a
"readable" file descriptor returns an "exceptional" file descriptor.
Later, when we try to read some data from the socket, the following
exception is raised:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
    self.run()
  File "/usr/local/lib/python2.5/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "_test2.py", line 14, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: (22, 'Invalid argument')

--- code ---

import socket, select, threading, time, os

def server():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(('', 1024))
    s.listen(1)
    conn, addr = s.accept()
    conn.setblocking(0)
    conn.setsockopt(socket.SOL_SOCKET, socket.SO_OOBINLINE, 1)
    while 1:
        r, w, e = select.select([conn], [conn], [conn], 0.01)
        if r:
            # the socket is supposed to be in the "readable" list
            data = conn.recv(1024)
            print "read -> " + data
        if e:
            # ...but not in the "exception" list
            data = conn.recv(1024, socket.MSG_OOB)
            print "expt -> " + data

threading.Thread(target=server).start()
time.sleep(0.1)
s = socket.socket()
s.connect(('127.0.0.1', 1024))
s.sendall('x', socket.MSG_OOB)

--- /code ---

[giampaolo]

This bug should be strictly related with bpo-3277:
http://bugs.python.org/issue3277

[gpshead]

This also happens on Linux:

read -> x
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/greg/sandbox/python/trunk/Lib/threading.py", line 523, in
__bootstrap_inner
    self.run()
  File "/home/greg/sandbox/python/trunk/Lib/threading.py", line 478, in run
    self.__target(*self.__args, **self.__kwargs)
  File "../socket_oobinline.py", line 20, in server
    data = conn.recv(1024, socket.MSG_OOB)
error: [Errno 22] Invalid argument

I need to look up what the exact behavior should be.

[gpshead]

p648 of Unix Network Programming third edition:

"4. If the process has set the SO_OOBINLINE socket option and then tries
to read the out-of-band data by specifying MSG_OOB, EINVAL is returned."

so it does not sound like a bug in Python.

There -does- appear to be a difference in BSD and Linux's socket
implementation here. select returned the socket in both the read and
exception list on Linux. While on BSD it only returned it in the
exception list.

The application is presumably supposed to keep track of which sockets it
has set SO_OOBINLINE on to know what to do when select returns them in
the exception state.

That said... OS X (and presumably FreeBSD) behaves oddly. The socket is
only ever returned in the e list and an attempt to conn.recv(1) from it
raises socket.error "error: [Errno 35] Resource temporarily unavailable"

[gpshead]

further reading reveals that this is the expected behavior.

p651 in 24.2: "select indicates an exception condition until the process
reads -beyond- the out of band data." ... "the solution is to only
select for an exception condition after reading normal data." with code
examples.

in short: if you want OOB with select there are hoops to jump through
for the edge cases. its layed out in the book.

[gpshead]

A friend confirms that on NetBSD it matches the Linux behavior.

"read -> x" is printed before the exception.

also fwiw, my OS X version is 10.5.3.

IMNSHO not a python bug. open it with FreeBSD and Apple.