- How can we tell if the next call to recv() will block?
We use the select() function to indicate which sockets are ready to be read from without blocking.
- How can you ensure that select() doesn't block for longer than a specified time?
You can pass select() a timeout parameter.
- When we used our tcp_client program to connect to a web server, why did we need to send a blank line before the web server responded?
HTTP, the web server's protocol, expects a blank line to indicate the end of the request. Without this blank line, it wouldn't know if the client was going to keep sending additional request headers.
- Does send() ever block?
Yes. You can use select() to determine when a socket is ready to be written to without blocking. Alternatively, sockets can be put into non-blocking mode. See Chapter 13, Socket Programming Tips and Pitfalls, for more information.
- How can we tell if a socket has been disconnected by our peer?
The return value of recv() can indicate if a socket has been disconnected.
- Is data received by recv() always the same size as data sent with send()?
No. TCP is a stream protocol. There is no way to tell if the data returned from one recv() call was sent with one or many calls to send().
- Consider this code:
recv(socket_peer, buffer, 4096, 0);
printf(buffer);
What is wrong with it?
Also see what is wrong with this code:
recv(socket_peer, buffer, 4096, 0);
printf("%s", buffer);
The data returned by recv() is not null terminated! Both of the preceding code excerpts will likely cause printf() to read past the end of the data returned by recv(). Additionally, in the first code example the data received could contain format specifiers (for example %d), which would cause additional memory access violations.
