Issue1309

Server sockets currently support three options: SO_RCVBUF, SO_REUSEADDR
and SO_TIMEOUT. Atttempts to set other options fail with an exception.

Client sockets have a number of options which are not applicable to
server sockets, e.g. SO_KEEPALIVE, SO_LINGER, SO_OOBINLINE,
SO_REUSEADDR, SO_SNDBUF, and TCP_NODELAY. In some socket
implementations, it is possible to set client-specific options on a
server socket, so that client sockets newly created with accept() can be
configured with (i.e. "inherit") those values. This is not currently
possible on jython.

The attached patch implements such functionality. But the patch contains
no unit tests, and is thus not yet ready for application to the socket
module.

Before the patch can be applied, the following questions must be addressed.

1. Currently java server sockets support SO_RCVBUF (through the
setReceiveBufferSize() method). This option has no meaning for server
sockets, but is used to configure newly 'accept'ed client sockets. Why
does java do this for SO_RCVBUF, but not for SO_SNDBUF?

2. Contrary to other socket implementations, e.g. BSD, Java specifically
does *not* inherit the SO_TIMEOUT value from server sockets to client
sockets. Given the proposed modification, how is an SO_TIMEOUT value set
on a server socket to be interpreted?
  - Stick with the java policy, and do NOT inherit the option?
  - Implement the BSD policy and inherit the option, even though that
may not be what the user intended?

3. What is the commonly accepted (BSD?) "inheritance policy" for
inheritance of the following client-specific options?

  - SO_KEEPALIVE
  - SO_LINGER
  - SO_OOBINLINE
  - SO_REUSEADDR
  - SO_SNDBUF
  - TCP_NODELAY
    - http://www.openldap.org/lists/openldap-bugs/200009/msg00191.html
    -
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/setsockopt.htm

These questions need to be answered by

A: Researching how other systems address these issues
B: Finding out what cpython does
C: Finding out what the python community expects

Having thought about this, my response is that the current behaviour
should remain, and that this bug should be closed as "won't fix".

Reasons include

1. All python socket module implementations defer to platform-specific
behaviour. I see no reason why jython should differ in this regard; it
should reflect the semantics of the underlying java platform, and not
inherit socket options if the underlying platform does not.

2. Doing this would force us to permit the setting of client socket
options on server sockets that are not valid for those server sockets.
This will lead to confusion among the users.

3. It is a simple exercise for the programmer to set whatever pending
options they wish on newly accept'ed client sockets.

However, rather than dismissing this RFE immediately, I will leave it
open for people to record dissenting opinions.

Whenever I develop a server in Python, I want it to run on as many
platforms as possible with few special cases as possible.

Making a choice such as this means you have to alienate one community or
another.  In this case, it's the community of developers who are porting
apps from Java to Jython versus the community of developers who are
trying to get their cPython apps to work on Jython.  This becomes the
question of "who is our target audience?"  I fall in the latter category
and hence strongly recommend that the behavior should match that of
every other Python implementation (regardless of underlying platform).

Principle versus practicality;  Newcomers or Established community.  It
depends on the goal of the project.

If you decide to maintain the Java-esque behavior, this should be a
documentation bug then.  Some Jython users are cPython users at the core
and don't understand the underlying Java platform behavior (myself
included).  There should be big flashy lights on a page about sockets in
the Jython documentation that explains the discrepancy between cPython
server socket behavior and Jython server socket behavior.  This is a
darn good idea for Python server implementers who want their servers to
run under Jython.  They need to know that they need to do something
specifically different to get the behavior they are expecting.

Hi Tim,

Thanks for taking the time to contribute to the discussion.

The problem I'm trying to address is this: If we are to emulate the
behaviour of cpython, then we should emulate the behaviour of cpython
running on which platform? AFAICT, the behaviour of cpython, in relation
to socket option inheritance, differs on each platform.

For example, BSD opts for inheriting socket level options (SOL_SOCKET),
but not TCP level (IPPROTO_TCP) options.

http://www.openldap.org/lists/openldap-bugs/200009/msg00191.html

AIX, inherits TCP level options.

"Beginning at AIX 4.3.2, TCP protocol level socket options are inherited
from listening sockets to new sockets. Prior to 4.3.2, only the
TCP_RFC1323 option was inherited."
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/setsockopt.htm

An accept'ed Window socket "has the same properties" as the parent
socket: no definition of option level.
http://msdn.microsoft.com/en-us/library/ms737526%28VS.85%29.aspx

Looking at the source code for the cpython socket module gives no help:
it has no code (that I can see) for transferring options from accept'ing
to accept'ed socket.

See lines 1608-1672
http://svn.python.org/view/python/trunk/Modules/socketmodule.c?view=annotate

So it appears to me that the cpython socket module is completely
deferring socket option inheritance to the underlying platform socket
library.

I work hard to make sure that the jython socket module is as compatible
as possible with cpython, and to make sure that cpython socket code runs
*without change* on jython.

But in this case, the behaviour of cpython is not specified. If there is
no clear statement of what is to be emulated, then how can I emulate it?

If there any specific standard which determines how socket option
inheritance should be treated, then I'll be happy to follow it.

That BSD/OS ML thread is old now, it looks like most BSDs and major OSes 
inherit at least TCP_NODELAY now. I verified that on OS X, Linux 2.6, 
Solaris 10, and FreeBSD 6.2 (and another ML post claims NetBSD inherits 
it too). So I'd want to be compatible with them in that respect, but 
that only answers part of the question. We need to know how the 
implementations deal with the other options too

Well, I see two options

1. Determine what the actual behaviour is for option inheritance in
cpython for all options on all platforms, then
  - See if there is identical behaviour on all platforms (that we care
about).
  - If option inheritance is identical on all platforms, implement it on
jython
  - If it is not, then things stay as they are

2. Implement an optional jython-specific method which
  - Permits the user to specify which options they wish to have inherited
  - Must be explicitly called by the user to take effect

Number 1 should not be too hard to investigate (and implement), as long
as I can get collaborators to run some cpython code I'll write, on all
the platforms we care about, and report back the results.

My gut feeling says we should go with option 2. This is a similar option
to what I did with select.cpython_compatible_select.

The main issue that I ran into is TCP_NODELAY for an RPC server I was
making.  The Nagle algorithm is horrible for fast response.  So from a
practical stand-point that's all I care about.

In either case (1 or 2), so long as the end behavior does not conform
with the majority case (cPython on Linux or Windows), we'll need obvious
documentation for this difference.  I'll put an entry in the wiki once
we come to a conclusion.

As for #1 testing, I can provide: Win(x86 and AMD64), Linux (x86) and
AS400 PASE (AIX 5.3 emulation).

Deferring to 2.6.

This behavioral change should be deferred until 2.7.

Speaking of which, we need to update the list of versions in the tracker, to at least include 2.7.

Just saw that 2.7a1 is indeed in the list.

Fix checked into tip at: http://hg.python.org/jython/rev/cb7e31929f49

Leaving bug report until documentation is updated.

Documentation updated: 

http://wiki.python.org/jython/NewSocketModule#Socket_options

Closing bug.