Networking recv

Understanding TCP recv() behavior in blocking sockets

This is a medium-difficulty networking question that tests your grasp of how the BSD socket API handles data reception in blocking mode. It commonly appears in interviews at firms that build trading infrastructure, market data handlers, or other latency-sensitive systems where engineers must understand socket semantics precisely.

The question probes whether you understand the contract of recv() on a blocking TCP socket: when data is available, what the function returns; what happens when the connection closes; how partial reads work; and the boundary between application buffers and kernel TCP receive windows. Many candidates conflate recv() with read-all-or-nothing semantics, which leads to incorrect reasoning about message framing and connection handling.

• Blocking vs. non-blocking socket modes
• Return value semantics (bytes read, zero on FIN, -1 on error)
• Partial reads and the relationship between requested size and actual bytes returned
• EOF signaling and connection state