Say you have a process that receives a large file from a server.

1. If you do not perform a recv() call does it stay on a buffer of your ethernet controller forever?

2. If another process needs to receive data and the buffer is full from another process does it need to wait until the other process performs a recv() or the buffer times out?

3. If you have multiple process sending and receiving data does it have to wait until the buffer is empty.? Or can it multiplex it and keep track at the driver level or some part of the socket library?

edit: spelling

CodePudding user response：

1. If you do not perform a recv() call does it stay on a buffer of your ethernet controller forever?

No, data never stays in the ethernet controller's buffer for very long; the kernel will read the data out of the Ethernet controller's buffer and into your socket's buffer (in the computer's regular RAM) as quickly as it can. If your socket's buffer is full, then the incoming data will be discarded.

2. If another process needs to receive data and the buffer is full from another process does it need to wait until the other process performs a recv() or the buffer times out?

Each socket has its own separate buffer in the computer's main RAM, and each process has its own socket(s), so processes do not have to wait for each others' buffers to empty.

3. If you have multiple process sending and receiving data does it have to wait until the buffer is empty.?

See the answer to question 2, as it answers this question also.

CodePudding user response：

This is a bit of perfectly spherical chicken in a vacuum type of answer. But your question is very broad and has a lot of what ifs depending on the NIC, the OS, and many other things.

But lets assume your are on a modernish full-blown OS, with modernish ethernet controller.

1. No. That all handled by the by kernel and protocol stuff. The kernel can't let the buffer on the network controller fill up while it's waiting for you. Otherwise it will block other processes from accessing the network. So it will buffer it up until you are ready. For some protocols there are mechanism where one device can tell the other device not to send any more data. (ei. TCP Receive Window Size, once the sender sent that amount of data it will stop until the receiver acknowledges it somehow)
2. It's basically the same answer as above, the OS handles the details. From your point of you, your recv() will not block any other processes ability to recv().
3. This is more interesting, modern NIC are queue based. You have n-number of transmit/receive queues, and in most cases, filters can be attached to them. This allows the NIC to do a lot of the functionality that normally would have to be done by the OS (that's called offloading) but back to the point. With these NICs, you have have multiple I/O without multiplexing. Though generally, especially on consumer grade NIC, the number of queues will be pretty low. Usually 4. So there will be some multiplexing involved.