Building a Windows client/server

Building a Windows-based server or client is not very different from the unix counterpart. Many of the calls are the same in both environments, but there are some differences dictated by the winsock header files.

In the Comer text used in previous years in CS611, there is a set of code that somewhat simplifies this process.  The example included below utilizes code from that text and the borland command-line c/c++ compiler, available both online and installed for your use on numerous machines in the ISL lab.

The compiler can be accessed from almost any drive/directory using the command-line DOS prompt as  long as the installation definition of the directory which holds the compiler binary still exists. You should be able to see something that looks familiar by typing "set" which will show you the PATH variable definition.

example:

C:\WINDOWS>SET
COMPEC=C:\WINDOWS\COMMAND.COM
TEMP=C:\WINDOWS\TEMP
...
PATH=D:\BUILDER\5\BIN

Assuming that is ok, the directories for include files etc. should not require much extra effort and the      compiler  itself can be executed by typing

C:\WINDOWS>BCC32 file1 file2 ....

Before going any further, try to compile and run a simple "hello world" application to make sure you understand how to use the compiler and to verify that it exists. You can use the simple DOS edit command to build your source.

Now that you can use the compiler, let's begin by examing a simple client. The client, chosen from the Comer text, is one which accesses a daytime server and simply displays the ascii text result returned from the server. In order to create this client, Comer created 4 files to use:

  1. tcpdtc.cpp which is the basic client -> tcp daytime client
  2. consock.cpp is an encapsulation of the creation and connection procedures you have seen
  3. errexit.cpp is a function which will print an error message and shut down the socket
  4. contcp.cpp is practically useless from your perspective and a result of a simple encapsulation strategy.

in order to compile the program you should only need to enter

c:\YourDirectory\bcc32 tcpdtc.cpp consock.cpp errexit.cpp contcp.cpp

and the compiler will create an executable named tcpdtc.exe

You may want to test this with the corresponding server routine which also has 4 routines as follows:

  1. tcpdtd.cpp which is the basic server -> tcp daytime daemon
  2. passsock.cpp is an encapsulation of the creation and connection procedures you have seen
  3. errexit.cpp is a function which will print an error message and shut down the socket
  4. passtcp.cpp is practically useless from your perspective and a result of a simple encapsulation strategy.

in order to compile the program you should only need to enter

c:\YourDirectory\bcc32 tcpdtd.cpp passsock.cpp errexit.cpp passtcp.cpp

and the compiler will create an executable named tcpdtd.exe

Simply run the server on the same machine and then ( in ANOTHER dos window) type the name of the client  You should see the output from the server displayed in the client window ,something like:

c:\YourDirectory\tcpdtc
Mon Jul 15 13:11:58 2002

Use Control-C to stop your server.

Observe that the client and server have code written in them to define default machine locations (localhost) and default port numbers (the predefined daytimed service) if you don't indicate otherwise. In order to override them, you simply enter them on the command line.

Also see how the client has to write a busy loop to be sure to read the entire response. While this is not really a big deal for such a short response as indicated above, it is the right way to be sure you get the entire response under a wide range of scenarios. You don't really need to understand how this works for this activity, but be sure to use it.

Now you only should need to make changes to the tcpdtc.cpp routine for your client or the tcpdtd.cpp file for your server.

Don't be confused by the fact that you might be running on two different operating systems. The adjustments you have made are more for the compiler than the OS. The applications don't care which API is used (winsock, bsd, etc.) as long as the protocols, hosts and ports are consistently defined. So this winsock application should work fine with a bsd socket application.

GOOD LUCK!