Created on 2009-04-08.10:23:27 by amak, last changed 2012-08-20.23:04:46 by amak.
|pending_client_options.patch||amak, 2009-04-08.10:23:25||A patch for allowing client specific options to be set on server sockets and propagated to 'accept'ed client sockets.|
|msg4480 (view)||Author: Alan Kennedy (amak)||Date: 2009-04-08.10:23:24|
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
|msg5271 (view)||Author: Alan Kennedy (amak)||Date: 2009-10-27.15:11:40|
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.
|msg5286 (view)||Author: Timothy Farrell (tercero12)||Date: 2009-10-28.14:20:17|
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.
|msg5287 (view)||Author: Alan Kennedy (amak)||Date: 2009-10-28.18:29:15|
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.
|msg5289 (view)||Author: Philip Jenvey (pjenvey)||Date: 2009-10-28.18:41:00|
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
|msg5292 (view)||Author: Alan Kennedy (amak)||Date: 2009-10-28.21:26:41|
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.
|msg5295 (view)||Author: Timothy Farrell (tercero12)||Date: 2009-10-29.14:47:39|
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).
|msg6074 (view)||Author: Jim Baker (zyasoft)||Date: 2010-09-20.18:54:38|
Deferring to 2.6.
|msg6818 (view)||Author: Alan Kennedy (amak)||Date: 2012-03-19.17:35:44|
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.
|msg6819 (view)||Author: Alan Kennedy (amak)||Date: 2012-03-19.17:36:22|
Just saw that 2.7a1 is indeed in the list.
|msg7416 (view)||Author: Alan Kennedy (amak)||Date: 2012-08-20.22:55:48|
Fix checked into tip at: http://hg.python.org/jython/rev/cb7e31929f49 Leaving bug report until documentation is updated.
|msg7417 (view)||Author: Alan Kennedy (amak)||Date: 2012-08-20.23:04:46|
Documentation updated: http://wiki.python.org/jython/NewSocketModule#Socket_options Closing bug.
|2012-08-20 23:04:46||amak||set||status: open -> closed|
messages: + msg7417
versions: + 2.7a2, - 2.7a1
|2012-08-20 22:55:49||amak||set||messages: + msg7416|
versions: + 2.7a1, - Deferred
|2012-03-19 17:35:45||amak||set||messages: + msg6818|
|2010-09-20 18:54:38||zyasoft||set||priority: high -> normal|
nosy: + zyasoft
messages: + msg6074
versions: + Deferred
|2009-10-29 14:47:40||tercero12||set||messages: + msg5295|
|2009-10-28 21:26:41||amak||set||messages: + msg5292|
|2009-10-28 18:41:00||pjenvey||set||messages: + msg5289|
|2009-10-28 18:29:16||amak||set||messages: + msg5287|
messages: + msg5286
|2009-10-27 15:11:41||amak||set||messages: + msg5271|
|2009-10-26 04:21:43||pjenvey||set||priority: normal -> high|
|2009-04-09 01:55:07||fwierzbicki||set||nosy: + fwierzbicki|