- 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 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.