Hi,
I checked the archives but didn't find anything that sounds like this...
For a homework assignment I have to write a datagram-driven client and
server pair. They are meant to be used by higher-level classes to handle
the underlying communication.
The client sends out numbered requests and waits for matching numbered
responses. In order to handle multiple simultaneous requests, I have
given the client a dedicated receiving thread. When a request is made,
the requesting thread sends a packet from a DatagramSocket, adds itself to
the list of waiting threads, and goes to sleep. When the receiving thread
receives a matching response packet from the server, it wakes up the
sleeping client.
All this information is a bit extraneous, but the point is this: there are
multiple threads using the same DatagramSocket for sends and receives. I
was under the impression that this was a valid and reasonable thing to do.
With JDK-1.2.2-FCS, I get strange behaviour. It seems that the receiver
thread is okay until the sender thread does a send() on the DatagramSocket
that the receiver is receive()-ing on. When this happens, the receiver
thread gets a "SocketException: socket closed" exception. This seems
strange because I did not connect() the socket, and I never call
close() in my code - the socket gets reused.
I created a smallish test class that demonstrates the behaviour. I ran it
on a Solaris box and got the behaviour I think is correct. A small
tarball containing the test source, output from running on my machine and
the Solaris box, plus version information from the two JDKs is available:
http://taz.cs.ubc.ca/~dustinl/socket-test.tar
(By the way, the output is of the form "[ <thread name> <time (s)>]
<message>". )
This is on kernel 2.2.19, libc 2.1.3, jdk 1.2.2-fcs, native
threads/sunwjit and green threads.
Thanks for your help!
dstn.
----------------------------------------------------
-- Dustin Lang, [EMAIL PROTECTED] --
User, n.: a particularly slow and unreliable input/
output device that is attached by default to the
standard input and output streams.
----------------------------------------------------
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
