I seem to be having some strange issues with my UDP NIO code. If my remote connection System.exit(0)s without proper termination it’s almost like UDP is timing out after a time…the SelectionKey is saying isReadable() but channel.receive(myBuffer) returns a null InetSocketAddress and the buffer receives 0 data. Is this expected behaviour and is there some way of detecting the address of the UDP (non-connection) that was lost? :o
It seems that that read comes back when I attempt to send a message that is undeliverable to the remote machine…I didn’t think UDP supported anything along those lines of letting you know that it never reached the destination?
[quote=“sunsett,post:2,topic:28063”]
Nope, the best you can do is get the client to ACK the message, if the server doesn’t get the ack then either a) the client never got the message, or b) the client got it, and sent the ack, but it got dropped on the way.
All you can do is then resend the original datagram. At the client side, you check if you already got that data, if you did, ignore it.
Now you are starting to get closer to running TCP over UDP, the more reliability and control you implement, the less worth while it is doing, you might just as well use TCP to start with.
On the other hand, if you want out of order, no garuntee of deliver, no throttling on congestion, then UDP is your friend.
HTH
Endolf
Well, with JGN I provide both options on the UDP layer. Back to the point though, why am I getting a null address on my read and receiving 0 bytes? I want to know what is causing this primarily just so I can understand what’s going on.
You’re probably getting a Port Unreachable type message on ICMP:
http://www.networksorcery.com/enp/protocol/icmp/msg3.htm
Kev
Interesting…wouldn’t that be considered a bug if it’s manifesting itself in Java like that? It would be great if it would throw back an exception that I can access the address from, but with just null and 0 it’s pretty useless and I end up ignoring it. This really isn’t a big deal except I’d prefer to be able to use it to my advantage to detect an unreachable host rather than have to do a noop timeout.
I’d consdier it a bug - however, they could argue that the socket address no longer exists so it’s been nulled. i.e. As a socket address it’s no longer valid.
I’m slightly surprised you don’t get a PortUnreachableException on trying to write to the channel?
It’s almost like you’d like an isErrored() on the SelectionKey 
Kev
isErrored() would be nice…actually ANYTHING other than what I’m getting now would be nice. :o
It’s possible I’m doing something wrong (though I can’t imagine how). This is my JGN project and it is moderately complicated code handling all of this…I might be confused, but I am certain that my read event is throwing a null address…that I am sure about.
It’s always possible we’re doing something wrong 
Do you check isValid() on the SelectionKey - the javadoc says:
A key is valid upon creation and remains so until it is cancelled, its channel is closed, or its selector is closed.
I would think if the port at the other end of the UDP “connection” is shutdown and it’s no longer possible to send packets to it that the channel would be considered closed. Though I suppose that’d only make sense if you’d connect()ed your datagram sockets in the first place.
Kev
I’m not using the connect() method since I’m potentially using the same DatagramChannel for multiple “connections”. I send everything with channel.send(bytebuffer, socketaddress).
While I’m iterating through my keys I do a isValid() check before I do anything else so that shouldn’t be the problem. I’ll try to find some time to look into this further, but for now I guess it will just have to remain a mystery. It’s not really hurting anything, it’s just not helping how I’d like.
Thanks