ECE/CS 438: Communication Networks Fall 2007Machine Problem 1 Due: 9:00 p.m. Friday, September 21Transferring Files over TCPPlease read all sections of this document before you begin coding.In this machine problem, you will develop a client-server application to transfer files to another computer. The clientwill accept interactive commands to obtain a directory listing or download a particular file and interact with the serverto execute them. The server will accept concurrent connections from multiple clients and serve them all correctly.ObjectivesThe primary goals of this machine problem are for you to learn to build simple client-server applications using thesockets API and for you to understand the process of sending messages over TCP. Servers generally manage multipleconnections simultaneously, and you should also learn the basics of concurrency from this problem.GuidelinesPlease work on this MP individually. Collaboration, discussion, code sharing, and any other form of group work isforbidden. Offenders will be dealt with appropriately (see the general information sheet available from the class homepage).You are required to make sure that your programs compile on the {dcllnx,gllnx,eelnx}*.ews.uiuc.edumachines and to use the EWS lab. Programs suffering compilation errors when tested by the course staff will earn nocredit.You may find it useful to read Chapters 1-4, 6, and 8 in Stevens. Refer to the Unix man pages as necessary. Youmay particularly want to look at man pages for opendir, readdir, stat, and getpwuid in order to generate thedirectory listingPlease indent and document your code. Use meaningful names for variables and follow other style guidelines thatenhance the clarity of your code.Follow the guidelines in the “Hand In” section below when turning in this assignment.SpecificationMake a directory called MP1 somewhere inside your main directory to hold your code. Call the file for your servercode server.c and call the executable server. Follow the same convention for the client. Note that the sourcefile names are recommendations; in contrast, the executable file names are requirements. Create a Makefile thatautomatically generates the executables from your sources.This problem consists logically of three components: a client thread, a main server thread, and a per-client serverthread. This document refers to the problem components as threads, and you are encouraged to use Posix threads toimplement them (see Chapter 23 of Stevens). In later machine problems, threads will become a requirement. However,for this problem, separate Unix processes are also acceptable. A third approach to supporting multiple clients is todevelop your own connection-specific context and to use a single thread of control.Client Specification:The client will be started with the following command:client serveraddress serverportwhere serveraddress and serverport are the address and port where the server will be running. The clientwill then wait for input from the user, which will consist of the following commands:• dir: Generate a listing of files in the current directory on the server.• get file: Download a copy of file from the server and save it to the current directory. If a file does notexist on the server, display an error message.• quit: Close the connection to the server and exit.• shutdown: Ask the server process to close all connections and exit. The client should also exit at this point.You should display a prompt “> ” before accepting each command. If an invalid command is entered, you shoulddisplay an error message and wait for the next command.Server Specification:The server will be started with the following command:server serverportIt will listen for connections from clients on port serverport. The clients will send commands according to theprotocol you designed and your server must respond to them appropriately. The server must be able to concurrentlycommunicate with several clients. If a client sends a shutdown command, the server should close connections to allclients and exit.Note: you should run your server and client in different directories, otherwise your client will be trying to overwritefiles that the server is reading.Listing Format:The directory listing must follow the format below exactly. You will be graded on the correctness of your file listingand you will lose marks for deviations.==== BEGIN DIRECTORY LISTING ====file1 nikita 1234file2 zhuang21 52333old.file root 15==== END DIRECTORY LISTING ====In particular, your listing must begin and end with the header and footer, exactly as above, with a blank line after theheader and before the footer. The listing contains three fields: the file name, the username of the file owner, and thefile size (in bytes). The fields are separated by a tab character (“\t”) and each line is terminated by a newline (“\n”).The files should be displayed in an alphabetically sorted order.Protocol Documentation:You will need to design a protocol for communicating between the server and the client. This protocol should bespecified (at the byte level) in a design document you hand in, and your server and client must follow the protocolduring their interactions. Your implementation of the protocol should account for byte order differences; you can testthis by trying to compile your program on a Sun machine (dclsn*or glsn*) and downloading files from there.For a bonus challenge, you can design your protocol to be more efficient when it transmits a directory listing. The topfew projects in the class will receive bonus points. However, make sure that your code functions correctly first; nobonus points will be given to projects that do not correctly produce listings.Refragmentation and Logging: One very important aspect of TCP byte streams that many people find difficult tograsp is the fact that calls to read and write (or send/recv, etc.) are not correlated. In particular, two or more writesto a connection can be received by the same read, and a single write can be split amongst several reads. The EWSenvironment makes this lesson harder because, on a local area network, the timing issues make it seem like correlationworks.To ensure that you gain a solid understanding of framing application data on a TCP connection, we have provided aroutine to make the environment much less predictable. In particular, you must use the interface below in place ofread for all of your MP1 client code (no calls to any other routine to read
View Full Document
Unlocking...