Multi-threaded access to a DatagramSocket

[Danny Woods]

Hi all,

Bit of an involved problem, this one, so please bear with me.

I have a DatagramSocket in an applet which handles the RTCP channel of an RTP
session. This channel is bi-directional, with very little server->client
communication. On the other hand, Client->server communication amounts to
about 10-20 small packets per second; packet loss on this channel isn't a
particular worry.

During operation, the call to receive will block, as the server won't talk
much. A second thread will call the send method as required on the same socket.
I have observed that this is not a problem: the socket appears to happily
process sends while blocked on the receive.

So here's the question: is the above reliable behaviour? There's no mention
in the documentation that this is ok.

Now, as this is an applet written with minimum browser requirements, it *must*
be written using the 1.1 APIs, thanks to Microsoft's VM. This rules out
java.nio's Selector with a DatagramChannel. I'm also not so happy
with using setSoTimeout() on the DatagramSocket to attempt a read before
handling the send requests, as each receive failure generates an
InterruptedIOException, and generating 10-20 exceptions a second isn't a
particularly efficient use of processor time (and just feels like a hack).

Any comments would be appreciated.

Regards,

Danny.

 

[Tim Ward]

So here's the question: is the above reliable behaviour? There's no mention
in the documentation that this is ok.

Tee hee.

You've got a good one there.

You don't complete the picture by asking what happens to the blocked thread
when a third thread closes the socket!

The answers are that the bugs vary between operating system, JVM version
etc. In native Windows most things happen as you would hope (although, as
you say, poorly documented if at all); there's at least one well-known bug
in this area on Solaris; what on earth Linux manages to do once you've got a
combination of threads, sockets and signals flying around, each of which
seems to have been designed in complete ignorance of each other, is
anybody's guess.

So far as Java version goes, on Windows, at least, some of this stuff works
better with 1.4.1, as there was at least one catastrophic bug in 1.4.0.

 

[Danny Woods]

Tee hee.

You've got a good one there.

Thanks, Tim. This is pretty much what I expected/feared. Testing this one
for the multitude of platforms/VMs it's required to support is going to be
a nightmare.

Danny.

 

[Steve Horsley]

Thanks, Tim. This is pretty much what I expected/feared. Testing this
one for the multitude of platforms/VMs it's required to support is going
to be a nightmare.

Danny.

The basic approach you take is sound though - stable and reliable.

The only problem is in closing a Socket while a thread is blocked on it. I
suggest you don't do that. Set a flag indicating you want to quit reading,
then send yourself a dummy packet to return the listening thread from its
blocked read. It should then check the flag, find it set, close the socket
and exit.

Alternatively, send a special shutdown message to yourself which the
reader thread will read and then close the socket and exit.

Alternatively, shutting the VM down will close things off of course.

Steve

 

[Danny Woods]

The basic approach you take is sound though - stable and reliable.

The only problem is in closing a Socket while a thread is blocked on it. I
suggest you don't do that. Set a flag indicating you want to quit reading,
then send yourself a dummy packet to return the listening thread from its
blocked read. It should then check the flag, find it set, close the socket
and exit.

Thanks, Steve. I've seen this approach elsewhere after some googling, and it's
the one I'll be going for: I wasn't happy about just closing a blocked socket,
either.

Danny.

 

[Tim Ward]

Thanks, Steve. I've seen this approach elsewhere after some googling, and it's
the one I'll be going for: I wasn't happy about just closing a blocked socket,
either.

Sending the dummy packet isn't always possible, for example if you have no
control over the other end of the connection, or if you're trying to talk to
something that's broken and the user presses the Cancel button rather than
wait several minutes for the complete stack timeout. Less of a problem for
stable services that run 24/7 but rather more of an issue for diagnostic
software tools that use TCP/IP to talk to flaky prototype hardware devices.

 

[Danny Woods]

Sending the dummy packet isn't always possible, for example if you have no
control over the other end of the connection

Sorry if I'm missing something here, but I didn't see a problem here. This
being a datagram socket, there is no 'connection.' Since I already have
sending and receiving threads in my applet, all I have to do is send a packet
addressed to the local host, which will unblock the receive? The true server
needn't get involved.

Apologies if I'm being thick (it's first thing in the morning, and I haven't
had my caffeine injection yet).

Danny.

 

[Tim Ward]

Sorry if I'm missing something here, but I didn't see a problem here. This
being a datagram socket, there is no 'connection.' Since I already have
sending and receiving threads in my applet, all I have to do is send a packet
addressed to the local host, which will unblock the receive? The true server
needn't get involved.

Yes, you can probably get away with this if you're only using UDP. When I
investigated this problem I needed answers for both UDP and TCP. (In fact
IIRC the problem with closing a socket on which something was waiting was,
counterintuitively, worse with UDP than TCP for one combination of OS and
JRE version.)