Socket Send Concurrency Guarantees

Socket send concurrency guarantees

You're asking that if you write() message A, then B on the same socket, is A guaranteed to arrive before B? For SOCK_STREAM (e.g. TCP) and SOCK_SEQPACKET (almost never used) sockets, the answer is an unqualified yes. For SOCK_DGRAM over the internet (i.e. UDP packets) the answer is no: packets can be reordered by the network. On a single host, a unix domain datagram socket will (on all systems I know) preserve ordering, but I don't believe that's guaranteed by any standard and I'm sure there are edge cases.

Or wait: maybe you're asking if the messages written by the two processes won't be mixed? Yes: single system calls (write/writev/sendto/sendmsg) always place their content into a file descriptor atomically. But obviously if you or your library splits that write into multiple calls, you lose that guarantee.

thread safety of concurrent read and write on a socket

As far as I know there is a single connection that is capable to send or recieve from one endpoint to other data at any given time.

Or both at the same time. It's a full-duplex connection. You can send and receive at the same time.

Unix Domain Socket concurrent read/write on both ends

The only relevant difference between an AF_LOCAL socket and an AF_INET socket is that AF_LOCAL sockets are local to the current computer. Creating an AF_LOCAL socket and binding it is no difference than creating an AF_INET socket and binding it to localhost.

The path used for binding AF_LOCAL sockets is only used for connecting to the socket, nothing else.

So if you create a connection-oriented AF_LOCAL socket (using SOCK_STREAM or SOCK_SEQPACKET) then each connection is unique and you can have multiple processes connecting through the same listening (passive) AF_LOCAL socket.

What socket send/recv operations can run concurrently using Boost.Asio

The same thing happens as would happen without Boost ASIO:

calling two async_send operations concurrently on an UDP socket.

Both datagrams will be sent.

calling two async_receive operations concurrently on an UDP socket.

It is arbitrary which operation will receive the next datagram, but both operations will behave normally.

calling two async_send operations concurrently on a TCP socket.

The data may interleave unpredictably.

calling two async_receive operations concurrently on a TCP socket.

The data may interleave unpredictably.

Send/ReceiveAsync: is order of calls guaranteed?

Yes. Imagine two .NET threads running two completion callbacks. The OS is now at liberty to suspend any one of them before the first instruction for any amount of time. For that phenomenon alone you can never rely on the order of call back invocation for concurrent IOs.

If you want ordering you need to sequence the processing yourself.

Is multithreading dangerous in sockets writing?

According to MSDN, the Socket class is thread safe. So, that means you don't need to lock the send method and you can safely send and receive on different threads. But be aware that the order is not guaranteed, so the data won't be mixed if you send it all at a single call to the send method instead of chuncked calls.

In addition to that, I would recommend to lock and flush it just in case you don't want the server swapping the responses across multiple concurrent requests. But that doesn't seems to be this case.

---

Related Topics