This is a Multi User Single Server File Transfer Application written in C Programming Language.
The application enables the user to perform client to server file(s) transfer tasks on Linux platform.
Server side implementation
Server side part of the application creates a new thread and further forks a new child for each client. The server has been designed using layered approach.
Server layer is responsible for handling incoming connections and creating separate thread for every connected client. If the client then requests a file transfer operation, a new process is forked for the client and the client is handled by this new child process. The client has to feed the username and password of a user account on server side machine to login.
The client sends a fixed size header specifying the number of bytes in the message its further going to send to the server. In the message client sends the command, command arguments and various flags for the command it wants the server to process. The server receives the fixed size header and after reading the header gets to know about the size of the message the client is going to further send and then receives those many bytes from the client.
A command selection layer scans the received message and according to the command specified in the layer places a call to the appropriate command processor for that command.
In the command processor (Command processing Layer) the command is further processed based on the options received from the client, and this layer sends data to the client if needed. The data may be something that is needed on the client side or it may be simply a response telling whether the command executed properly on the server side or not.
Since command selection and command processor layers are kept seperate, new command processors for new commands can be easily added in the future. The server application can be started as both a foreground service and a background service.
To shut the server application down, a shutdown script is provided which on execution shuts down the server program which results in further incoming connection requests not getting accepted. But the child processes of the server process serving the connected clients remain alive and keep serving the clients till the client decides to end the session.
The port to which the server binds to is kept in a configuration file.
Client side implementation
The client side part of the application has been divided in various layers.
The UI Layer is responsible for providing an interactive text based interface for the user. Output handlers and Error handler callback functions have to be provided by the UI layer to the command parsing layer.
The next layer is responsible for command parsing. It accepts the command string from the UI Layer. The command parsing layer separates the commands and arguments. Commands are validated and the command arguments are passed on to the appropriate command processor (command processing layer).
The command processor prepares a message containing the command, arguments, flags to send to the server and then first sends a header specifying the length of the message its further going to send and then sends the message.
The client receives a header from the server specifying the length of the response the server will further send. Then it waits to receive those many bytes of response. This response may specify whether the command was processed successfully on remote side or not (and if not then why not?), Based on this response according to the specific command the client can decide whether to wait for further data from the server or not.
On errors, a English error message is provided by the command processors to the error handler callback specified by the UI layer. On success the strings to be printed are provided to the output handler callback specified by the UI layer.
The user can issue commands to be implemented for local system or remote system.
The text user interface can be easily replaced with graphical user interface by changing the UI Layer. Even web based interface can be integrated with ease.
For data security, api's like openssl can be used in future. They can be integrated easily in the existing code since the network programming code is limited to the library functions and is not present directly in the UI layer, command parsing and processing layers. So openssl can be integerated without changing he UI layers, command parsing and processing layers with just a change in those library functions containing the network programming code.