- 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_clientprogram 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 withsend()?
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 causeprintf()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.
