Programmer Name: Ritesh Jain Net Id: rjain1 Course: cs338, Spring '2000 Date: Feb 16, 2000 Part 1: IMPLEMENTATION LOG There are two files: client.c and server.c 1. client.c: client.c parses the command-line arguments given to it and if the arguments are correct, it tries to establish a connection with the server. If connected, it frames the sentences read at the prompt (through fgets) and sends each across the network to the server. A wrapper function is used to handle partial writes. In case the mp1_write command returns 0 or -1, an error condition is signalled. A character array is used to support the frame formats and simple for and while loops are used to traverse through it, incase, to stuff bits like 0 for format3, and E for format 4. 2. server.c: server.c creates a socket and then listens for connections from clients. For each client, it creates a new socket. It also creates a new process using fork. It first receives the frame type from the client, and depending on the format, reads the TCP stream, deformats the data, and prints it on the screen along with the IP address of the client who sent it. Partial reads are handled differently for the different framing types, as described later. A character array is used to support the frame formats, and is traversed using simple for and while loops. Interesting aspects: 1. The client can detect if the server has crashed, or the link is broken due to any unforeseen reasons. When the pipe (link) is broken, mp1_write returns -1 and errno is set to EPIPE. To ignore the event SIGPIPE caused by this, a signal was setup. 2. Partial writes were handled. It may be possible for the mp1_write() to write only partial (less number of bytes than specified) data on the stream, TCP being a purely byte stream. So, a wrapper function was written by the name mp1_wrapper_write() which would write exactly the number of bytes specified, or would exit if the pipe was broken. 3. Partial Reads were handled: Again, it may be possible that data less than or more than a frame may be read by one mp1_read call. For this, again a wrapper function by the name mp1_wrapper_read() was written, which would read exactly the number of bytes specified. Since for format 3 and 4, we do not know in advance the frame size, the wrapper function is no use. To handle partial reads for these formats, the only way is to traverse the character array till the sentinel is found. If there are still more bytes, instead of discarding them, put them into a new buffer to be used by the subsequent read call. If no sentinel is found, continue reading till either the sentinel is found or the buffer capacity is full, in which case, just print an error message. Acknowledgements: The original initialization code for server and client was copied from "Beej's guide to Internet programming". prototypes and objects for mp1_* funtions were taken from the course directory. Part 2: Experimental Results: Following is the output at the client when the given sentences are piped into the client call. FORMAT 1 eesn14> client eesn10 1 < /homesta/ece338/MP1/sentences bytes in sentence: 46 bytes sent across the network: 50 efficiency: 0.920000 bytes in sentence: 72 bytes sent across the network: 100 efficiency: 0.720000 bytes in sentence: 67 bytes sent across the network: 100 efficiency: 0.670000 closed connection with server.. eesn14> FORMAT 2 eesn14> client eesn10 2 < /homesta/ece338/MP1/sentences bytes in sentence: 46 bytes sent across the network: 50 efficiency: 0.920000 bytes in sentence: 72 bytes sent across the network: 76 efficiency: 0.947368 bytes in sentence: 67 bytes sent across the network: 71 efficiency: 0.943662 closed connection with server.. eesn14> FORMAT 3 eesn14> client eesn10 3 < /homesta/ece338/MP1/sentences bytes in sentence: 46 bytes sent across the network: 94 efficiency: 0.489362 bytes in sentence: 72 bytes sent across the network: 146 efficiency: 0.493151 bytes in sentence: 67 bytes sent across the network: 136 efficiency: 0.492647 closed connection with server.. eesn14> FORMAT 4 eesn14> client eesn10 4 < /homesta/ece338/MP1/sentences bytes in sentence: 46 bytes sent across the network: 47 efficiency: 0.978723 bytes in sentence: 72 bytes sent across the network: 74 efficiency: 0.972973 bytes in sentence: 67 bytes sent across the network: 71 efficiency: 0.943662 closed connection with server.. eesn14> Format 2 seems to be more efficienct and least complex. Format 1 appends too many extra blanks in case of short frames, hence the efficiency suffers. Format 3 is the least efficient because almost every alternate byte is a 0. Format 4 is quite efficient for the sentences given above, but for a large number of E's or $'s in a sentence, the efficiency will drop. Besides, the complexity is pretty high because of the destuffing that needs to be done. Hence, format 2 which has very high efficiency (not the highest in these examples, 4 being higher) and least complexity (although 1 is less complex) is the most appropriate for TCP connections.