Networking API Issues

Networking API Issues

A network is a very hostile place, and making assumptions about whether a connection is still valid can get you into trouble. Never make networking calls from inside a critical section if you can possibly avoid it. All sorts of things can go wrong, ranging from a connection being dropped before you have a chance to send, to a malicious client setting a miniscule TCP window size.

bind

Be careful when binding to INADDR_ANY (all interfaces) you might be at risk of socket hijacking. See Chapter 15, Socket Security, for details.

recv

This function has a trinary return, and all three possibilities aren't always trapped. An error is -1, a graceful disconnect (or end of buffer) returns 0, and a positive number indicates success. In general, it's a bad idea to call recv using a blocking socket. Under certain error conditions, a blocking recv can hang a thread indefinitely. For high performance, use WSAEventSelect. It may not be portable, but the performance gains are worth it.

send

This function sends data to a connected socket. Do not assume that all the data was successfully transmitted if send succeeded. Connections sometimes drop between the call to connect and the send. Additionally, if someone is maliciously setting your TCP window size to a very small value, the only way you'll notice it will be if the send call starts to time out. If you have the socket set to blocking or don't check the return from this function, you've just opened yourself up to a denial of service condition.

NetApi32 calls

These calls are tremendously useful and return all sorts of information about Windows systems. Examples include NetUserGetInfo, NetShareEnum, etc. Unfortunately, they are all blocking calls. If you need these calls, plan on working around the fact that they will block, usually for 45 seconds, sometimes longer. A second caveat is that if you end up dealing with non-Microsoft SMB (Server Message Block) implementations, you could get unusual behaviors. For example, a Microsoft system might always give you a valid pointer if it succeeds, but a non-Microsoft system might give you a NULL pointer. Just as a server should never assume a benign client, a client application should never assume a well-behaved server.