4

I have been reading about UDP sockets in python.

By default a socket is configured so that sending or receiving data blocks, stopping program execution until the socket is ready. Calls to send() wait for buffer space to be available for the outgoing data, and calls to recv() wait for the other program to send data that can be read.

I understand the receiving part, it has to wait till the other end sends. but why would the send block? It says in the book: "send() waits for buffer space to be available". What's the buffer space?

Is it for the whole Operating System or is it defined for every application running.

Is there a way to know how much buffer space is available?

bubakazouba
  • 1,633
  • 2
  • 22
  • 34
user3571278
  • 721
  • 5
  • 15
  • 1
    Are you looking for a fully general, portable answer, or a practical answer for some specific platform? – abarnert May 25 '15 at 00:00
  • 1
    Meanwhile, this really isn't a Python question at all; Python's `socket` is just a thin layer over the (BSD sockets) file descriptor or (WinSock) WSA handle, and by tagging this Python-specific, you're limiting the number of people who will see and answer this. – abarnert May 25 '15 at 00:05
  • @abarnert just removed the python tag. – user3571278 May 25 '15 at 05:35
  • @chepner Your deleted answer is totally incorrect. There are *two* socket buffers: send and receive. Please don't post misinformation here. – user207421 May 25 '15 at 05:44
  • Does this answer your question? [When does a UDP sendto() block?](https://stackoverflow.com/questions/4165174/when-does-a-udp-sendto-block) – tstenner Nov 25 '20 at 10:59

1 Answers1

1

The buffer referred to by the BSD sockets and POSIX documentation, and presumably also by whatever you were reading, is a per-socket buffer, not per-system or per-app. It's the same one you can set with SO_SNDBUF. When that buffer is full, send will block.

But the real question is, why would that buffer get full?

Underneath the stuff your app can see, the kernel usually has something like a ring of transmit buffers per NIC. When the NIC finishes putting a buffer worth of data out on the wire, it pulls another one off the ring. When there's space on the ring, it pulls another transmit buffer from one of the socket buffers. Or, if there are too many buffers waiting, it drops some of them and then pulls one. So, that part is system-wide (or at least NIC-wide).

So, just knowing your send buffer size doesn't really tell you everything you really care about, and to truly understand it you need to ask questions specific to your kernel. If that's Linux or a *BSD, the networking stack is open source and pretty well documented (in Linux, if I remember correctly, and if my 2.4-era knowledge is still useful, searching for SO_SNDBUF and txqueuelen give you good starting points); otherwise, it may not be. Of course Linux exposes all the information there is to expose somewhere in the /proc filesystem, so once you know what you want to look for, you can find it. *BSD doesn't expose quite as much, but there's a lot of stuff there. Even Windows has a slew of performance counters that are relevant.

abarnert
  • 354,177
  • 51
  • 601
  • 671
  • buffer --> ring of buffers --> NIC-wire so a buffer will be full if the ring of buffers is full, and a ring of buffers would be full if the NIC never finished putting a buffer worth of data out on the wire i.e a socket would be blocked (for a very small amount of time) if there are alot of other buffers waiting to be put on the wire and it would be blocked forever if there is a problem with the NIC (like being disconnected from the network) Do I understand correctly? – user3571278 May 25 '15 at 06:10
  • @user3571278 Yes, but remember the part about buffers just being discarded if the NIC gets behind, so UDP sends don't ever have to get blocked forever, they can just get 100% packet loss without even getting to the network. (At least that's one way a kernel could implement things...) – abarnert May 25 '15 at 07:03
  • 1
    Can you recommend me a book to start with to undertsand more about how sockets work? – user3571278 May 25 '15 at 07:20
  • 2
    @user3571278 Whatever book I used a few decades ago is probably not the best choice today. Unix Network Programming is a great intermediate resource, but for really deep stuff you need to go platform-specific, and for the high-level overview it's not the simplest read (especially if you don't already understand C and the Unix file model well). – abarnert May 25 '15 at 07:28