This occurs only on Windows 2000 in "receive" method of DatagramSocket class. 
When client socket comes into recieve method without any server 
socket, we get an unexpected java.net.SocketException like this:

[thread MyThread]:exception occurred java.net.SocketException: socket closed
java.net.SocketException: socket closed
        at java.net.PlainDatagramSocketImpl.receive(Native Method)
        at java.net.DatagramSocket.receive(DatagramSocket.java:392)
        at MyThread.run(MyThread.java:15)

It doesn't happen on Windows NT, Solaris. And, if you start server socket 
prior to client, you will not get any exception. 

I got this exception with JDK1.1.8, JDK1.2, and JDK1.3. 

To reproduce this problem with sample code, you should do as follows;
- compile following 3 java files attached
- Type "java DatagramClient" in prompt.

[Note] You need not DatagramServer.java to reproduce it. 
I'm attaching it only for reference. 

If the DatagramSocket is connected then you must close and
re-create the socket.

If not connected then you can retry the receive as the first
receive will consume the ICMP message. It may be necesary to
retry multiple times because Windows 2000 returns a "connection
reset" for each ICMP message (unlike BSD behaviour).

In Windows 2000 the ICMP "port unreachable" is exposed to java.net
via a WSACONNRESET status on the next recvfrom/sendto after the 
previous send operation resulted in the ICMP message. This is new
behaviour compared to 95/98/NT. As the datagram code doesn't 
recognize all the window sockets return codes it is assumed to be
a socket closed and hence the SocketException in the test case.

 xxxxx@xxxxx  2000-08-17

Here's the discussion thread about this issue on Winsock-2 
mailing list (including an official confirmation of this 
Win2K behaviour from the program manager of win networking 
at MSFT) :

http://www.stardust.com/cgi-bin/wa?
A2=ind9905&L=winsoc&F=&S=&P=15160

The only workaround I could see for this nasty problem is 
to catch the IOException and immediately close the current 
socket and create a new one on the same port - ugly fix but 
seem to work well enough...

The cleaner 90% java fix would be to plug in some native 
code that uses the appropriate IOCTL call to turn off this 
behaviour on Win2K SP2. See this MS KB article for info on 
this :
http://support.microsoft.com/support/kb/articles/Q263/8/23.A
SP

Hope that helps until Merlin comes out!

When a SecurityManager is present, the same call should
result in 
java.net.SocketException: Connection reset by peer: Datagram
peek failed.

I have the exact same problem running on linux Red Hat 6.1

I think there is more to this problem than stated here. I 
ran in to this and after tracing it to receiving a 
WSACONNRESET I researched why I might be receiving that. It 
turns out that a proper UDP implementation is supposed to 
notify the sender when a receiver it though existed no 
longer exists as determined by the "port unreachable" ICMP 
message. This notification is made by raising such an error 
on the next receive. It was considered a bug in previous 
version of windows that it did not do this. That java 
treats this as a "socket closed" SocketException is wrong, 
but it should also not ignore it. There may be programs 
that rely on a SocketException for notification of a 
receiver that went away. A good solution might be to throw 
a subclass of SocketException that indicates what really 
happened.