Issue1018

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, -
1)

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

fd=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
rnetLoc = ('0.0.0.0', 12000)
fd.bind( rnetLoc )

while True:
    print "waiting....at", rnetLoc
        
    fd.setblocking(0)   # jython 
    s,_,e = select.select( [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 ('127.0.0.1', 12001)
        # in Python works fine.
    
--------------------------
#UDP Client
import socket
import select
import time

fd=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
rnetLoc = ('0.0.0.0', 12001)
fd.bind( rnetLoc )

rnetLoc = ('127.0.0.1', 12000)
while True:
    
    print "sending....at", rnetLoc
        
    fd.setblocking(0)   # jython 
    _,s,e = select.select( [] , [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 
        time.sleep(2)
-----------------------------------------
I hope this helps

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)

On 4/3/08, Alan Kennedy <report@bugs.jython.org> wrote:
>
>
> Alan Kennedy <jython-dev@xhaus.com> 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-1.6.0.03

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)

 IPv4

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 <report@bugs.jython.org>
> <http://bugs.jython.org/issue1018>
> _______________________________________
>

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

http://wiki.python.org/jython/SelectModule#head-b6728987f9d2e872721ecf2174ad98e116b33292

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.

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
java.net 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
java.net.

I will investigate further.

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."

I'm fairly sure that this bug is caused by a bug in java, relating to
DatagramPackets received through DatagramSockets created through
DatagramChannel.open(). 

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 java.net, 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.

Uploading the client side.

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

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

Thanks Alan for your interest. I hope Sun's techicians have taken this 
issue in consideration for future revisions.

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.