Blocking sockets: when, exactly, does “send()” return?

by

Does this mean that the send() call will always return immediately if there is room in the kernel send buffer?

Yes. As long as immediately means after the memory you provided it has been copied to the kernel’s buffer. Which, in some edge cases, may not be so immediate. For instance if the pointer you pass in triggers a page fault that needs to pull the buffer in from either a memory mapped file or the swap, that would add significant delay to the call returning.

Is the behavior and performance of the send() call identical for TCP and UDP? If not, why not?

Not quite. Possible performance differences depends on the OS’ implementation of the TCP/IP stack. In theory the UDP socket could be slightly cheaper, since the OS needs to do fewer things with it.

EDIT: On the other hand, since you can send much more data per system call with TCP, typically the cost per byte can be a lot lower with TCP. This can be mitigated with sendmmsg() in recent linux kernels.

As for the behavior, it’s nearly identical.

For blocking sockets, both TCP and UDP will block until there’s space in the kernel buffer. The distinction however is that the UDP socket will wait until your entire buffer can be stored in the kernel buffer, whereas the TCP socket may decide to only copy a single byte into the kernel buffer (typically it’s more than one byte though).

If you try to send packets that are larger than 64kiB, a UDP socket will likely consistently fail with EMSGSIZE. This is because UDP, being a datagram socket, guarantees to send your entire buffer as a single IP packet (or train of IP packet fragments) or not send it at all.

Non blocking sockets behave identical to the blocking versions with the single exception that instead of blocking (in case there’s not enough space in the kernel buffer), the calls fail with EAGAIN (or EWOULDBLOCK). When this happens, it’s time to put the socket back into epoll/kqueue/select (or whatever you’re using) to wait for it to become writable again.

As usual when working on POSIX, keep in mind that your call may fail with EINTR (if the call was interrupted by a signal). In this case you most likely want to call send() again.

More Related Contents:

  1. Can two applications listen to the same port?
  2. What do you use when you need reliable UDP?
  3. What are the use cases of SO_REUSEADDR?
  4. Difference between TCP and UDP?
  5. Size of empty UDP and TCP packet?
  6. Can TCP and UDP sockets use the same port?
  7. What is “backlog” in TCP connections?
  8. Connection refused – tcp socket in linux [closed]
  9. convert TCP/IP to Address name on LAN network
  10. How do I debug error ECONNRESET in Node.js?
  11. What is the theoretical maximum number of open TCP connections that a modern Linux box can have
  12. Detecting TCP Client Disconnect
  13. Does a TCP socket connection have a “keep alive”?
  14. UDP vs TCP, how much faster is it? [closed]
  15. How does the socket API accept() function work?
  16. What does it mean to bind a multicast (UDP) socket?
  17. how to achieve transfer file between client and server using java socket [duplicate]
  18. Setting the source IP for a UDP socket
  19. Linux: is there a read or recv from socket with timeout?
  20. Python socket.accept nonblocking?
  21. Problems with SO_BINDTODEVICE Linux socket option
  22. close() is not closing socket properly
  23. Simple Socket Server in Bash?
  24. When should I use TCP_NODELAY and when TCP_CORK?
  25. How do I check if a Socket is currently connected in Java? [duplicate]
  26. Specifying UDP receive buffer size at runtime in Linux
  27. localhost vs real ip address
  28. How do I get amount of queued data for UDP socket?
  29. Reading from udp port in browser
  30. How to close a socket left open by a killed program?

Leave a Comment