CSC 552 - Advanced Unix Programming, Fall, 2008 - Faculty Home ...

CSC 552 - Advanced Unix Programming, Fall, 2008 Program 3, TCP/IP sockets, DUE 11:59 PM, November 24 Dr. Dale E. Parson, [email protected], http://faculty.kutztown.edu/parson Below is the class diagram for assignment 3. It expands my solution to assignment 2, which I will post before class on November 10. The only addition to the class diagram is that there is a new plugin class, RemotePythonchess, that implements the game interface by connecting a client-side TCP/IP socket to a remote invocation of the Python chess game. Your assignment is to write and test plugin RemotePythonchess, which (like your other plugins) takes the form of a shared .so library file. You must also write a server-side TCP/IP socket program startConnectedProcess that serves access to a Python chess game as described below. Client framework that connects to one or more game sessions, either by interception of running processes, or by starting a game process, and translates board update messages between them. game Abstract virtual member functions from assignment 2.

xboardGchess interceptor

Pythonchess fork/exec manager

RemotePythonchess client socket manager

Class Diagram for Assignment 3 The component diagram for your assignment appears on the next page. You need to write two programs, the .so plugin RemotePythonchess that manages the client side of a TCP/IP connection to a remote Python chess game, and startConnectedProcess, a stand-alone C++ program that sets up the server side of a TCP/IP connection to this remote Python chess game. Program startConnectedProcess consists of a C++ main() function and any helper functions that you decide to write, that does the following. 1. It takes as its first command line argument the name of a TCP port, and attempts to serve a TCP socket on that port. If the attempt to obtain that port fails, then this process must ask the operating system to assign it a port. Use my code in ~parson/UnixSysProg/tcp/serverdemo.cxx as a guide for obtaining a port. Notice what happens when two concurrent invocations of that server request the same TCP/IP port:

CSC 552, Fall, 2008, programming assignment 3, page 1 of 3

xboard (from GNU)

client framework (main)

game

game

game

xboardGchess

RemotePythonchess

Pythonchess

pipes gnuchess (from GNU) Component Diagram for Assignment 3

TCP/IP sockets startConnectedProcess

pipes

python chess (from Parson)

python chess

/export/home/faculty/parson/UnixSysProg/tcp -bash-3.00$ ./serverdemo 4000 & [1] 5770 -bash-3.00$ attempting to listen and serve machine v245-2, port 4000 listening for client connection requests -bash-3.00$ ./serverdemo 4000 & [2] 5778 -bash-3.00$ attempting to listen and serve machine v245-2, port 42854 (UNIX assigns this port) listening for client connection requests 2. Your program must print out similar information to STDOUT and STDERR, and then wait for a connection request from a TCP client. 3. The second command line argument to your program is the path to an executable program, and the subsequent command line arguments are the command line arguments for that


program. In this assignment the path to the Python chess gamestart program serves as the executable path, and any subsequent arguments (if any) serve as arguments to gamestart. Incidentally, I have installed a fix to my Python chess program so that, if it is invoked concurrently in multiple processes, it will use ports assigned by the operating system. Those ports are UDP ports used to communicate with Python chess GUI processes. They do not affect your assignment. Your server process waits for only one connection request from a TCP/IP client, which it grants. Once it has granted that connection, it must do the following steps. 3a. Close the listen socket, so that it will not accept any subsequent client connection requests. 3b. Replace its STDIN file descriptor (fd) with its server-side socket fd. 3c. Replace its STDOUT file descriptor (fd) with its server-side socket fd. 3d. Exec the path to its application, retrieved from the command line argument, with the command line parameters. In this assignment that means execing the Python chess game. Notice that there is no fork call. The parent replaces itself with the Python chess game. If the exec call fails, print an error message to STDERR and exit with a documented, non-0 exit code. After the exec, Python chess’ STDIN and STDOUT are connected to the socket, and its STDERR remains connected to the invoking terminal, unless STDERR was redirected on the command line that invokes program startConnectedProcess. Given the operation of program startConnectedProcess, the job of plugin RemotePythonchess is similar to your previous Pythonchess plugin, except that RemotePythonchess opens a client socket to the startConnectedProcess-initiated Python chess game, writing to the STDIN of Python chess and reading the STDOUT of Python chess via the client socket fd. Clearly, you must have some means of passing both the IP address and the TCP port of the server machine to your plugin at run time. Environment variables are OK for this assignment; a configuration file would be another alternative. You cannot assume that the client and server are on the same machine, and you cannot assume that the server IP address or port is always the same. Running them on the same machine is a viable testing strategy. See my code in ~parson/UnixSysProg/tcp/ clientdemo.cxx for an example of setting up a client-side socket connection. This assignment must be able to run with two or more plugins, and ANY of them may supply the next move, which your program must pass on to the other plugin instances. I may solve that problem in my solution to assignment 2, in which case you can use my solution in assignment 3. We will not slip the due date on this assignment, because we need to get to a multithreaded assignment before the end of the semester.
