About Server Programs
This chapter is meant to discuss the approach to building server programs. A server program may, or may not have a user-interface in the traditional sense. An example of a server program would be a program that accepts TCP/IP connections and then responded to requests by carrying out some process and then returning a result to the caller. A web server, a dedicated XML server that acts as a gateway to a database, a mail server, a payment gateway, a graphics server that converts images from one format to another, a file update system; these are all typical server programs.
Accessing Server Programs
There are a few different ways of accessing a server program. Most modern systems will use either TCP/IP, UDP/IP, a communications port (COM1, USB001, OLE2, DDE, etc.), the file drop method (monitor a directory and when a file appears in the directory read and process it), or they may use some other intermediary such as an ini file. Currently SIMPOL can be used to implement such systems using TCP/IP, file drop, or ini files (SIMPOL supports OLE2, but only as a client program).
Sample TCP/IP Server and Client Programs
Two sample programs are shipped with SIMPOL. They can be found in the
\SIMPOL\Projects\sockets directory. One is called clientsample and the other is
serversample. Together they implement a very rudimentary file transfer system that could fairly easily be built into a live update type of mechanism.
They each contain a
receivestring() function that was taken directly from a commercial application built in-house. This particular function design requires that the other end respond with a carriage-return linefeed pair or a linefeed alone (should work fine on Windows, Linux, and OS-X). The function was designed so that it can also work together with directly typed input, such as from Telnet. The server simply sits there doing nothing until a connection is made. At that point a new thread is spawned and passed to the
dispatch() function, along with the incoming socket object.
dispatch() function a HELO is sent to identify the server as a response to the connection. A loop is entered to process the commands supported by the server. If nothing arrives within a specific amount of time, then the loop will time out and the connection will be closed. The client receives the HELO and then requests the time by sending the TIME command. After receiving the time from the server, it sends the GET command and the server responds by opening and then transmitting its own program file, prefaced with a minimal header to tell the client the amount of data being sent. The client receives the data using the
receiveblob() function and stores it. It then sends the QUIT command to allow the server to exit the loop immediately rather than waiting for a time out.
Server Programs Conclusion
Although the sample program is quite basic, it is actually very powerful. With minor modifications it could easily send whichever file was requested. It could modify the header to send the file name, size, date and time of last modification, and even optionally send the data compressed and/or encrypted, using existing library code supplied with SIMPOL. With minor modifications it could also provide a query mechanism where the client sends a LIST command, for example, and it would then examine a designated directory and return the file name and last modified date and time for each file to the client. The client could then compare these with its own copy of each and request any file that was newer than the copy it already holds (plus any missing ones). Using the ability of the
UTOSdirectoryentry object to set the date and time, the client could make sure that the local copy always has the same date and time as the server one. This sort of application could also be implemented as a web server program.