Question

When i was taking a look at setsockopt from msdn link. i came across a parameter SO_RCVTIMEO, it description is “Sets the timeout, in milliseconds, for blocking receive calls.” I thought the socket listen operation is event driven which means when kernel drained frame from NIC card it notify my program socket, so what is the blocking all about?

Answer 1

The recv and WSARecv functions are blocking. They are not event driven (at least not at the calling level). Even when blocking has a timeout (as set with the SO_RECTIMEO option), they are not event driven as far as your code is concerned. In that case, they are just pseudo-blocking (arguably non-blocking depending on how short the timeout is).

When you call WSARecv, it will wait until data is ready to be read. While data is not ready to be read, it just waits. This is why it’s considered blocking.

---

You are correct that at it’s core networking is event driven. Under the hood, computers are, by nature, event driven. It’s the way hardware works. Hardware interrupts are essentially events. You’re right that at a low level what is happening is that your NIC card is telling the OS that it’s ready to be read. At that level, it is indeed event based.

The problem is that WSARecv waits for that event.

---

Here’s a hopefully clear analogy. Imagine that you for some reason cannot leave your house. Now imagine that your friend F lives next door. Additionally, assume that your other friend G is at your house.

Now imagine that you give G a piece of paper with a question on it and ask him to take it to F.

Once the question has been sent, imagine that you send G to go get F’s response. This is like the recv call. G will wait until F has written down his response, then he will bring it to you. G does not immediately turn around and come back if F hasn’t written it yet.

This is where the gap comes from. G is indeed aware of the “F wrote!” events, but you’re not. You’re not directly watching the piece of paper.

Setting a timeout means that you’re telling G to wait at most some amount of time before giving up and coming back. In this situation, G is still waiting on F to write, but if F doesn’t write within x milliseconds, G turns around and comes back empty handed.

Basically the pseudo code of recv is vaguely like:

1) is data available?
  1a) Yes: read it and return
  1b) No: GOTO 2
2) Wait until an event is received
  2a) GOTO 1

---

I know this has been a horribly convoluted explanation, but my main point is this: recv is interacting with the events, not your code. recv blocks until one of those events is received. If a timeout is set, it blocks until either one of those events is received, or the timeout is reached.