On 02 Jul 2004, at 18:44, mds wrote:

> Just came across a suspected bug while hacking with UDP sockets, the
> simple task being to send a piece of data to a given port and a given
> hostname.
>
> Connection itself is successful, a call to #sendData: however, is not.
>
> Here's the code I tried from a workspace:
>
>
> 	"---------------------------------------"
> 	s := Socket newUDP. s disconnect.

The problem is that it isn't clear (insofar as the Squeak VM is 
concerned) what it means to "disconnect" a UDP socket.  They aren't 
really ever connected; sending one a #connectTo: just sets up a 
temporary association with a remote peer allowing data to be sent and 
received without specifying the peer's address explicitly every time.

So #disconnect could mean either of two things:

   - close the socket (as if it were a TCP socket), never to allow it to 
be used again;

   - dissolve any temporary association with a remote peer that might 
have been set up with #connectTo:.

The current interpretation (in the Unix VM) is the former (simply by 
accident, since there is no test to see what kind of socket is being 
disconnected in the code).  This doesn't work well with the other 
primitives which, for UDP sockets, don't bother to check for 
"connected" status.

I think the correct solution would be to change the interpretation of 
#disconnect in the VM for a UDP socket to simply undo the effects of 
any previous #connectTo:, leaving the socket intact but dissolving any 
temporary association with a remote peer that #connectTo: had 
previously set up.  (This is trivial, and is equivalent to sending the 
socket #connectTo: again, with a wildcard peer address.)  The reason I 
think this is the correct solution is that it keeps the effects of 
#connectTo: and #disconnect "symmetrical" w.r.t. UDP sockets.

Unless anyone has any objections to this (including, but not limited 
to, it making the Unix VM behaviour diverge slightly from other 
versions of the support code for UDP socket handling) I will make the 
necessary changes today, ready for a new release of the VM to conincide 
with the gamma image.  (In any case, the current behaviour is 
demonstrably incorrect and requires a fix one way or the other.)

Cheers,
Ian