Title: UDP recvfrom fails to get the remote address
Type: Severity: normal
Components: Library Versions: 2.2.1rc1
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: amak Nosy List: amak, asterio, fwierzbicki
Priority: normal Keywords:

Created on 2008-04-01.08:17:50 by asterio, last changed 2013-02-25.23:41:45 by amak.

File name Uploaded Description Edit Remove
unnamed asterio, 2008-04-03.20:38:13 amak, 2008-04-08.15:59:32 A pure java server which illustrates the problem. amak, 2008-04-08.16:00:25 A pure java client to send packets to the server
msg3112 (view) Author: asterio (asterio) Date: 2008-04-01.08:17:49
When a UDP socket try to read from a remote socket, the data is 
received right, but the remote address, ports always are set to (None, -

I give a two simple codes that reflects this issue.
#UDP Server
import socket
import select

rnetLoc = ('', 12000)
fd.bind( rnetLoc )

while True:
    print "", rnetLoc
    fd.setblocking(0)   # jython 
    s,_,e = [fd] , [], [fd], 10)
    for r in s:
        print "Activity from", r.getsockname()
        fd.setblocking(1)   # jython 
        raw, rnetLoc = r.recvfrom(4096)
        fd.setblocking(0)   # jython 
        #rnetLoc = '%s:%s' % rnetLoc
        print "%s from %s" % (str(raw), str(rnetLoc)) # jython always 
give (None, -1) instead something like ('', 12001)
        # in Python works fine.
#UDP Client
import socket
import select
import time

rnetLoc = ('', 12001)
fd.bind( rnetLoc )

rnetLoc = ('', 12000)
while True:
    print "", rnetLoc
    fd.setblocking(0)   # jython 
    _,s,e = [] , [fd], [fd], 10)
    for w in s:
        print "Can write using", w.getsockname()
        fd.setblocking(1)   # jython 
        print rnetLoc
        l = fd.sendto('Hola', rnetLoc)
        fd.setblocking(0)   # jython 
I hope this helps
msg3116 (view) Author: Alan Kennedy (amak) Date: 2008-04-03.19:25:54
Thanks for the detailed report, the code is most helpful.

What would also help is some of the following information.

1. Version of jython (revision number if using trunk)
2. Version of java running jython
3. Operating system
4. Network cards using IPv4 or IPv6? (I'm guessing v4 from your code)
msg3117 (view) Author: asterio (asterio) Date: 2008-04-03.20:38:13
On 4/3/08, Alan Kennedy <> wrote:
> Alan Kennedy <> added the comment:
> Thanks for the detailed report, the code is most helpful.
> What would also help is some of the following information.
> 1. Version of jython (revision number if using trunk)

jython 2.2.1

2. Version of java running jython

 jre is java-6-sun-

3. Operating system

Linux and Windows with jre 1.6 as well.

4. Network cards using IPv4 or IPv6? (I'm guessing v4 from your code)


If you need any additional information, code snippets or whatever, please
let me know.
This is an error that I know from the beta of jython2.2

> assignee:  -> amak
> nosy: +amak
> _______________________________________
> Jython tracker <>
> <>
> _______________________________________
msg3130 (view) Author: Alan Kennedy (amak) Date: 2008-04-07.20:39:04
One thing I'd like to point out to you is that you can avoid all those
setblocking(0|1) calls to switch on and off for select'ing by using the
cpython_compatible_select function, added for exactly this situation. To
use it, either call select.cpython_compatible_select() directly, or
import like this

from select import cpython_compatible_select as select

More details from here

If you really want to be using the sockets in non-blocking mode, you
should perhaps consider the asyncore and asynchat modules as a model for
writing your servers and clients.
msg3131 (view) Author: Alan Kennedy (amak) Date: 2008-04-07.21:39:32
Actually, the bug is partially fixed already, but not in 2.2.1. The fix
is checked into the 2.2 release branch, and will appear in 2.2.2. You
could of course download the latest version from SVN (URL below).

If you use the latest (fixed) module, when the socket is in either
blocking or non-blocking mode, the fixed code uses the java.nio apis,
which do not present this problem.

However, if you change your socket into timeout mode, then the old code path is used, and the bug still appears. Change the
setblocking(1) call before the udp_server.recvfrom, and you will see the
bug re-appear.

This seems to be caused by the the DatagramPacket.getAddress() call
returning null, which prevents getting at the information about from
whence the packet was received.

I have yet to ascertain why this happens, but think this may be a bug in
java DatagramPackets, relating to the fact that the DatagramChannel is
created with the java.nio APIs, but the packet is received using the

I will investigate further.
msg3132 (view) Author: Alan Kennedy (amak) Date: 2008-04-07.21:40:41
Actually that should have read "Change the
setblocking(1) call before the udp_server.recvfrom to a settimeout(1.0)
call, and you will see the bug re-appear."
msg3136 (view) Author: Alan Kennedy (amak) Date: 2008-04-08.15:59:32
I'm fairly sure that this bug is caused by a bug in java, relating to
DatagramPackets received through DatagramSockets created through 

I have reported the bug to Sun, but it may be a few days before they get
to review it and publish it.

I have attached the source of pure java server and client which
illustrates the issue.

The server can be run in one of two modes.

1. If no command line parameter is present, the DatagramSocket is
created through, and the problem DOES NOT occur.

2. If a command line parameter "create_nio" is present, the
DatagramSocket is created through java.nio (as happens in the jython
socket module), and the problems occur.

I have noted this as a "Known issue" with the jython socket module, but
it cannot be fixed until the underlying bug in java is fixed.
msg3137 (view) Author: Alan Kennedy (amak) Date: 2008-04-08.16:00:25
Uploading the client side.
msg3458 (view) Author: Alan Kennedy (amak) Date: 2008-08-28.16:31:37
Although I reported this bug to Sun 4 months ago

 - I still haven't received any acknowledgement from Sun
 - The bug has not been made public on the Sun bug database
 - The bug has not been fixed
msg4444 (view) Author: Alan Kennedy (amak) Date: 2009-04-05.13:57:04
It's year since I reported this bug to Sun, but

 - I've heard nothing from Sun
 - The bug as not appeared on the Sun bug database
 - The bug has not been fixed, as of JDK 1.6.0_13
msg4455 (view) Author: asterio (asterio) Date: 2009-04-06.16:22:55
Thanks Alan for your interest. I hope Sun's techicians have taken this 
issue in consideration for future revisions.
msg7775 (view) Author: Alan Kennedy (amak) Date: 2013-02-25.23:41:45
I've tested this bug again with the latest JDKs. The results are

jdk1.5u22: FAIL
jdk1.6u41: FAIL
jdk1.7u10: PASS

So, in order to get around this issue, you will have to upgrade to the latest JDK 1.7, where it was actually fixed.

Closing this issue: there is nothing more to do in jython.
Date User Action Args
2013-02-25 23:41:45amaksetstatus: open -> closed
resolution: fixed
messages: + msg7775
2009-04-06 16:22:55asteriosetmessages: + msg4455
2009-04-05 13:57:04amaksetmessages: + msg4444
2009-03-14 13:50:52fwierzbickisetnosy: + fwierzbicki
2008-12-17 19:50:41fwierzbickisetpriority: normal
2008-08-28 16:31:37amaksetmessages: + msg3458
2008-04-08 16:00:25amaksetfiles: +
messages: + msg3137
2008-04-08 15:59:33amaksetfiles: +
messages: + msg3136
2008-04-07 21:40:41amaksetmessages: + msg3132
2008-04-07 21:39:32amaksetmessages: + msg3131
2008-04-07 20:39:04amaksetmessages: + msg3130
2008-04-03 20:38:14asteriosetfiles: + unnamed
messages: + msg3117
2008-04-03 19:25:55amaksetassignee: amak
messages: + msg3116
nosy: + amak
2008-04-01 08:17:50asteriocreate