site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Godfrey, On Feb 1, 2010, at 18:40 , Godfrey van der Linden wrote: After a few messages the client, closes its socket. Someone with more current knowledge may be able to shed more light. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds ----------- I'm beginning to like the cut of his jibberish. ----------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I'm trying something a bit different for performance testing and have tripped over a problem that I just haven't been able to solve. Maybe you netheads out there can enlighten me. I have a pair of threads each of which have independent AF_UNIX, SOCK_DGRAM sockets. The client knows the servers AF_UNIX address and connect()s the client socket to the server before sending the first message. The server on recvfrom()ing the first message then connect()s the server's socket to the received client's address. Then falls into a simple mirror loop, that is send a reply, block in recv(). Q> Shouldn't the server's blocked recv() call be aborted with an ECONNRESET error, when the client's socket is closed? This is just a guess, since it's been an eon or so since I delved into the code behind the API, but I believe that, for SOCK_DGRAM, the 'connect' function is used essentially to store destination address information (so you don't have to provide it with every datagram). I'm pretty sure that SOCK_DGRAM does not come with real 'connection' semantics (so in particular, there's no way for one end to tell the other that the local user has closed/disconnected). It's certainly the case for UDP, but for AF_UNIX, I'm not so sure. This email sent to site_archiver@lists.apple.com