Reference no: EM131929918

Assignment

The purpose of this assignment is to discover how to author client-server applications that communicate over sockets (network connections). To make this interesting, we are going to replicate the venerable rsh command that was available on the original UNIX systems. rsh stands for remote shell. Namely, it is a client that is used to access the server hosted on a remote system. For simplicity's sake, we are going to run the client and the server on the same machine, but your code should work just as well on a remote machine.

There are clearly two parts to complete: the server and the client. Both server and client can be implemented with a total of less than 150 lines of code. In this assignment, you receive an empty folder and you must produce everything (Makefile and source code for the two programs: client.c and server.c). The executables are rsh and rshd. Make sure you adhere to the naming directives! Good luck!

Important: Remember that we are implementing applications that work in networked environments. It is almost certain that your implementations (or even the protocol you are asked to implement) will have vulnerabilities. They are not production ready and you should not deploy them on real systems!. There is a reason why rsh is no longer favored as a good solution for remote shell (these days we all use ssh). And we ask you to test your code, both client and server, on your local machine only. The focus of this exercise (and some other assignments in this course) is on understanding the mechanics of client-server communications over sockets. To understand the risks and security features that you would like to include in your programs, you will have to take other courses (e.g., computer security, cryptography, network security, etc.).

Exercise 1.Server

Your server should be accessible on localhost and port 8025. Your implementation uses the IPv4 stack and the TCP (byte stream) transport layer. The server listens for inbound request to talk and, upon reception of such a request, spawns a child process responsible for running the bash shell (this is your default shell and is available under /usr/bin/bash). A shell should be started as a login shell (option -l for bash). Note that a shell uses all three standard streams stdin, stdout, and stderr, and sockets are full-duplex and bi-directional.

Clearly, a spawned child process should take care of the necessary re-directions for bash to work properly.

Finally, the parent process (the rshd daemon) should collect the dead processes regularly to fully release resources back to the OS.

Your server executable should be named rshd. You can execute it from a shell from the command line and it will listen for inbound client requests. If implemented correctly, your daemon is inter-operable with the rsh client of any of your peers! You can run rshd and use the following command to test your server in a separate terminal.

Note that the remote shell daemon you are creating is not meant to provide any advanced capabilities like authentication or terminal emulation. It is only suitable for simple line oriented commands like those used in the pipeline in the previous homework. You are NOT asked to start the shell in the interactive mode (option -i). So you will not see the shell prompt.

Exercise 2. Client

Your client should be called rsh and take the name of the target host as the first argument on the command line. Clearly, for testing purposes, you would invoke the client with the argument localhost to contact the rshd server you are running on your UITS VM in another terminal.

The client is pretty straightforward. It sets up a socket to contact the server on port 8025, obtains commands from the standard input, forwards them to the remote shell, and displays on its standard output the messages coming back from the remote shell. For example, a working implementation should be able to submit simple commands such as ls, cd, pwd, cat, echo , ... to the remote shell and display the results on its local standard output.

The sole delicate point lies in how to choreograph the two activities: reading from the standard input and reading from the socket connected to the remote shell. Neither of the readings is blocking.

In case some of you are wondering, you CANNNOT simply turn your client into other programs (like nc).