   recvfrom returning 0xffff?!
  when my socket on the other end disconnects, I first get the packet that signals that client is disconnecting. then, when I call select/recvfrom the next time, I get 0xFFFF as the return value, even though nothing was sent. WSAGetLastError returns WSAECONNRESET, or ''Connection forcibly closed''. on a connectionless socket?! what is going on here, do I have to close my socket a special way to not trigger this to happen? 
  What is this about disconnecting a UDP socket? Do you actually mean closesocket() or shutdown() was called, or ''disconnect'' in the general sense in which your communication protocol sends "disconnection notice" packets?btw, 0xFFFF == -1 == SOCKET_ERROR ;  i thought SOCKET_ERROR = 0? doh, that would be part of my problem.either way, that leaves me with socket failing (instead of my recieve function getting a 64k packet ) I do both, send a disconnect notice, and then close the socket, it assumes it won't be recieving an ack for the disconnect notice (which it doesn't). the only problem is after the client socket is closed, the server socket is unusable (returns SOCKET_ERROR for everything i try to do to it). i left the socket options to default, and MSDN says the default is SO_DONTLINGER, which is a graceful disconnect.   [edited by - billybob on February 5, 2004 2:20:42 AM];  a 0 return from recv() indicates a closed connection, and a call to closesocket() can follow. ;  I don''t see what ANY of this has to do with a datagram socket, i thought it was connectionless? do you mean the socket has become un-bound? ;quote:Original post by billybob   I don't see what ANY of this has to do with a datagram socket, i thought it was connectionless? do you mean the socket has become un-bound?   oh geez, ignore that...In some weird fashion I misinterpreted udp recvfrom() into tcp recv()...sorry about that. EDIT: Though the return value is still zero for a graceful close.   [edited by - nervo on February 5, 2004 2:26:32 AM];quote:Original post by Nervo  oh geez, ignore that...In some weird fashion I misinterpreted udp recvfrom() into tcp recv()...sorry about that. EDIT: Though the return value is still zero for a graceful close.   no problem I understand 0 is for a graceful close, but I don''t want it to close, or become ''errored''. the client socket doesn''t have any trouble, its only the server socket, when the client socket on the other end is closed, it somehow is ruining the server socket it was transferring data with.;  On a UDP datagram socket, when recvfrom() sets the WSAECONNRESET it  means that the last send operation resulted in a ICMP: port unreachable error. Which probably means a previous packet got sent to the socket that was just closed. ;quote:Original post by SiCrane  On a UDP datagram socket, when recvfrom() sets the WSAECONNRESET it  means that the last send operation resulted in a ICMP: port unreachable error. Which probably means a previous packet got sent to the socket that was just closed.   does this ICMP error not cause the error to be triggered on the send operation? because I''m 100% positive that I check the return code of all sends, and none of them are setting any errors. this means that the sendto is not blocking, so its receiving the ICMP port unreachable error after sendto has returned. if only you could step backwards in the debugger ;  No. If the port is closed on the destination host on a sendto() call with a datagram socket, it won''t signal an error on the sendto(). Waiting for a return packet kind of defeats the purpose of using an unreliable connectionless protocol. Besides which, an ICMP packet isn''t generated for every sendto() that you call, so the sendto() implementation wouldn''t know when to wait for an ICMP packet or not. 