Discussion:
How (un)reliable are local domain sockets?
(too old to reply)
Jan Danielsson
2013-07-30 20:43:21 UTC
Permalink
Hello,

Say I'm adding the necessary ACK's, retries, etc to a UDP based
protocol, and I want to support local domain sockets as well (also
SOCK_DGRAM). Do I need to keep the "error handling" from the UDP code,
or are local domain sockets guaranteed to be successful as long as
sendto() was successful?

I found this:
http://stackoverflow.com/questions/1566980/how-reliable-are-unix-domain-sockets

..which has the magic "as on most Unix implementations" words in it,
which doesn't say much, unfortunately.

It wouldn't be difficult (in fact, it would be pretty trivial) to
simply rewire the code so that larger packets are used for local domain
sockets, but apart from that the code is more or less identical.
However, if the new code would - in practice - never need to resend any
packets, I would prefer to allow the code path for local domain sockets
to be only as complex as it actually needs to be.

Perhaps I should add support for both, and simply use a macro to
switch between modes. But the question remains: On NetBSD, are they
reliable?
--
Kind regards,
Jan Danielsson


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Thor Lancelot Simon
2013-08-03 17:10:25 UTC
Permalink
Post by Jan Danielsson
Hello,
Say I'm adding the necessary ACK's, retries, etc to a UDP based
protocol, and I want to support local domain sockets as well (also
SOCK_DGRAM). Do I need to keep the "error handling" from the UDP code,
or are local domain sockets guaranteed to be successful as long as
sendto() was successful?
You want to be careful with this. Though on BSD implementations, local
sockets have always been reliable, you have no such guarantee on mutant
Unices such as Linux.

In particular, Linux is prone to reorder messages on local
sockets and in some cases can drop them. If you want to indicate
to the kernel expressly that you don't countenance such behavior, you
can use SOCK_SEQPACKET rather than SOCK_DGRAM, but, then
your code may not compile...

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...