A program that establishes a TCP connection with a remote server, sends a local file to the server for processing, and receives and stores the processed file in the local file system. Watch a GIF of me interacting with it below!
- Server
ECHO
: The server sends back the same data it receives from the client without any modification. - Server
ZIP
: The server receives data from the client, compresses it using the GZIP format, and sends it back to the client. - Server
UNZIP
: The server receives GZIP compressed data from the client, decompresses it, and sends it back to the client. - The client opens a TCP
Socket
to communicate with the server; it first sends the service code provided as a command line argument to the server, followed by the input file to be processed. At the same time (ie. simultaneously), it reads the server's processed file chunks from theSocket
and writes them to the output file. The server works analogously in the opposite direction (it reads the regular file from theSocket
, processes it, and writes to theSocket
). - The server continues reading from its
Socket
input stream by repeatedly calling theread()
method until it returns-1
(indicating the stream is at the end of the file). The client signals to the server that transmission is complete (allowing it to stop its reading) by callingshutdownOutput()
to close its side of the connection. The client can no longer send but can still read the processed data coming from the server (analogous to sending a segment withFIN = 1
); the client state goes fromESTAB
->FIN_WAIT1
->FIN_WAIT2
. See the image below:
In the above image, we see that the client can still receive data from the server even after sending a segment with FIN = 1
. This is exactly what is happening in our
program; the client closes its side of the connection after the entire file is sent, but continues reading the processed file from the server.
- Client uses a parallel rather than serial design to prevent deadlock; with a serial design, the client would need to transmit its entire file before reading from the server. For very large files, the client would not yet read anything from its
Socket
; theSocket
buffer would quickly fill up with the server's processed data. This would then block the server when it callswrite()
on theSocket
output stream (this is the flow control of TCP and is how theSocket
is designed); a blocked server would not read from itsSocket
input stream, which then blocks the client. Both the client and server would be blocked, leading to a deadlock. The client uses two threads to work around this; one for sending data, and another for reading processed data.
-i <input_file>
specifies the name of the file to be processed by the server; REQUIRED-o <output_file>
specifies the name of the processed output file; defaults toinput_file.out
-c <service_code>
specifies the service code requested from the server;0
isECHO
,1
isGZIP
,2
isUNZIP
. Defaults to1 (GZIP)
.-b <buffer_size>
specifies the buffer size in bytes used for writing the file to the server and reading processed data. Defaults to10000
.-p <port_number>
specifies the server's port; default is2025
.-s <server_name>
specifies the server's hostname; default islocalhost
.
-p <port_number>
specifies the server's port; default is2025
; the-p
flags should match when running both the client and server. Otherwise, the client will be unable to connect.-b <buffer_size>
specifies the buffer size (in bytes) used at the server for read/write operations; default is1000
.quit
shuts the server down if it is already running.
-
Start the server by running
streamserver.jar
, as follows:cd server java -jar streamserver.jar [-b <buffer_size>] [-p <port_number>]
- Start the client by compiling all files and running
ClientDriver.java
, as follows:
cd client
javac *.java
java ClientDriver -i ../files/<input_file>
[-o <output_file>]
[-c <service_code>]
[-b <buffer_size>]
[-p <port_number>]
[-s <server_name>]