This section expands on topics already introduced. Please read the other sections first.

Recv Loop

You may remember that I said the recv loop in ADRSockSrv was "not robust enough for production applications". The reason for this statement is that the received message does not necessarily contain a single complete command. It could potentially be delivered one character at a time (ok, not very likely, but possible). Or the client could have neglected to disable the Nagle algorithm so that we receive a batch of commands in one message. The recv call is simply overlaying the sBuffer each time. ADRSockSrv works because ADRSockClient is carefully written to use short messages in a controlled manner. If you write a server that works with a variety of client programs then it must be more flexible than this demonstration.

A proper server accumulates the received characters and parses them into commands. The commands are passed to the ADR card one at a time. The response for each command is read from the serial port before the next command is written to the serial port. The ADR card treats the serial port as a half-duplex connection, writing out a new command obliterates the response from the previous command.

This enhancement is not difficult to add, but would impair the clarity of the tutorial.

Multi-Threading

Sockets are ideal for multi-threaded servers. The main tutorial stressed that an accepted socket is "a socket in its own right". This allows you to spawn a thread that handles the accepted socket while the parent process loops back to accept another connection through the listening socket.

Microsoft provides a CSocket class for TCP/IP programming. Unfortunately the CSocket class is not thread-safe. (now you know why I presented the "bare" socket API instead of the MFC class.) If you do not need multi-threading then you may elect to use the CSocket class in your program. At least this tutorial gives you an idea of the kind of processing that the CSocket class encapsulates.

The Hosts File And Domain Name Services

For our TCP/IP sample we edited the Hosts file and manually typed in an IP address with its associated computer name. If we have multiple client computers then we must ensure that each client has the correct IP addresses and computer names in its local Hosts file. Now imagine that we are in an organization with hundreds of computers. Maintaining all those version of the Hosts file is getting mighty tedious. Now imagine that we are on the Internet with millions of computers. Whoa, our Hosts file mechanism won't work!

Domain Name Services (DNS) is the mechanism through which human-readable addresses are translated into dotted octet addresses. You may have had to type in an address for a DNS server when you installed your Internet connection. (Perhaps you did not see it if your ISP provided an installation program). The gethostbyname call uses DNS to resolve names into addresses. The Hosts File allows local over-rides and additions to the DNS tables. (so we can easily test programs like ADRSockClient).

The traffic used to maintain the DNS server databases is a huge drain on net resources but it beats memorizing the dotted-octet addresses of all the machine you access.

gethostbyname

Okay, the truth is that we did not need the Hosts file for our sockets demo. ADRSockClient will accept the dotted-octet IP addess in place of the server computer name. The gethostbyname call is clever enough to recognize an IP address and place it into the host entry that is returned. So instead of:

ADRSockClient myserver y pa

you can type:

ADRSockClient 10.0.0.1 y pa

assuming that 10.0.0.1 is the IP address of the computer named "myserver". The gethostbyname call is necessary for a real client so I included it in the demo. (You aren't going to make users of your program type in dotted-octet address are you?)

Cheap Tricks with the Hosts File

First save a copy of your Hosts file. You will need it to reverse your changes.

Say there is a remote machine on your network that is not being resolved by your DNS server. You go over to it and ping your own machine. It works! Ah ha, the remote machine sees your computer but you cannot see it. Here is something that you can try. Copy down the IP address of the remote machine. Back at your own computer edit the Hosts file and add a line with the IP address and name of the remote machine. Ping the remote machine to see if you can now see it.

Or perhaps you want to re-direct your network traffic to another server. Save a copy of your Hosts file first. Then edit your Hosts file to include a line for the IP address of a machine that duplicates the service that you need.

If you have problems then restore your original Hosts file. Warning: Your net admin may not be pleased if you call for support after mucking up the Hosts file.