Python: cannot set socket option SO_REUSEPORT

[nils-werner]

I cannot set SO_REUSEPORT to 1 on a socket in Python. I am aware that SO_REUSEPORT does not exist on Windows, however many Python libraries make use of it.

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 22] Invalid argument

It fails in both Python 2.7 and 3.4 on Windows Build 14393.447

sudo apt-get install python2.7 python3.4
python2.7 -c 'import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)'
python3.4 -c 'import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)'

Related answers on StackOverflow:

• 'SO_REUSEPORT' is not defined on Windows 7
• Socket options SO_REUSEADDR and SO_REUSEPORT, how do they differ? Do they mean the same across all major operating systems?

both

>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

work fine.

[choleraehyq]

on Windows Build 14956

Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 92] Protocol not available
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
>>>

[jackchammons]

@nils-werner It looks like this has been fixed on newer builds of Windows. Can you upgrade to an insider build and see if that solves your issue?

I may have spoken too soon. Checking up on this and will update the thread when I know more.

[nils-werner]

I am not member of the Insider Program, sorry. Can you please state the build number so others can confirm?

[sunilmut]

Support for SO_REUSEADDR was added in 14915. SO_REUSEPORT is not yet supported.

[nils-werner]

This is not an issue in Python for Windows, by the way.

[christianparpart]

Thanks @sunilmut for the headsup wrt. SO_REUSEADDR, however, any ETA on SO_REUSEPORT? I need it for my own apps to run on WSL, and I'd love to continue being happy. Can we can an ETA on the implementation. And an ETA on the (somewhere) promised list of not-yet-implemented syscalls?

Thanks in advance, and keep up the good work. Christian.

[sunilmut]

Unfortunately, SO_REUSEPORT is not natively (and exclusively) supported by the Windows networking stack. We brought this to their attention before, but it didn't make the cut earlier. We will be revisiting this soon. Will get there. Thanks for your patience.

[straight-shoota]

Judging from the initial report, it seems that getsockopt with SO_REUSEPORT used to fail on WSL. That's the expected behaviour if SO_REUSEPORT is not supported.

However, I can't reproduce this. Using a simple test program from https://gist.github.com/straight-shoota/3f235b0cc046111806cba1d0d5195915

• setsockopt(sock, SOL_SOCKET, SO_REUSEPORT, (void*)&reuse, size) returns 0
• getsockopt(sock, SOL_SOCKET, SO_REUSEPORT, (void*)&reuse, &size) returns -1

Windows build number: Version 10.0.17134.228

This behaviour is very unexpected. Either SO_REUSEPORT should be supported (which probably won't be possible with Windows' network stack) or setsockopt should fail when setting SO_REUSEPORT.

/cc crystal-lang/crystal#6706

[therealkenc]

getsockopt(sock, SOL_SOCKET, SO_REUSEPORT, (void*)&reuse, &size) returns -1

Looks like that is worthy of a new issue. There is a line in the 16273 release notes circa August 2017 that says "Stub SO_REUSEPORT" but no update here since Sunil's last comment in June 2017. It is possible (probable) that setsockopt() was stubbed but getsockopt() was not. I am not sure if it was an oversight or deliberate.

Either SO_REUSEPORT should be supported (which probably won't be possible with Windows' network stack) or setsockopt should fail when setting SO_REUSEPORT.

No because stubbing setsockopt(...SO_REUSEPORT, ...) gets past hard blockers for the common case, where the reuse semantics are sought but not actually put to work (the port is never actually reused by another socket). Ie, it wasn't stubbed for its health. The open question is whether getsockopt() should lie too. I could make a case either way, but without thinking too hard about it I suspect the answer is "yeah probably".

[abdulrehman3222]

I was having a similar issue with

WSL: 1, Ruby: 2.5.0, Rails: 4.2.1, and Puma: 3.8.0

my rails s was working I was getting the following error whenever I send a Get request:

    Read error: #<Errno::ENOPROTOOPT: Protocol not available - getsockopt(2)>
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/server.rb:124:in `getsockopt'
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/server.rb:124:in `closed_socket?'
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/server.rb:563:in `handle_request'
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/server.rb:425:in `process_client'
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/server.rb:289:in `block in run'
    /home/abr/.rvm/gems/ruby-2.5.0@helpy/gems/puma-3.8.1/lib/puma/thread_pool.rb:120:in `block in spawn_thread'

I struggle a lot for fixing that issue even I try the above solution but that didn't work either.

at last, I found a simple solution that I need to update my Pum from 3.8 to 3.12+ and it works perfectly for me.

[chanpreetdhanjal]

Hi. Can you please collect networking logs by following the instructions below? https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues