Suraj Kurapati <skurapat@ucsc.edu>
CMPE-150, Spring 2004
Network Programming Project

CONTENTS:

    files
    instructions
    specification
    known problems
    comments
    references

FILES:

    html/
        API documentation generated by Doxygen tool.

    Makefile
        Compilation script.

    README
        General project overview.

    siftp.[ch]
        Provide syntax & semantics for the SimpleFTP protocol. They also
        provide transport level services such as sending and receiving
        messages.

    service.[ch]
        Provide a common interface for mainly session level services. They
        also provide some application level services that are common to both
        server & client.

    client.[ch]
        The SimpleFTP client.

    server.[ch]
        The SimpleFTP server. Is able to handle multiple connections and has a
        simple authorization system via a common password.

INSTRUCTIONS:

    Compiling the programs.

        Run the command 'make all'.

        To view debugging messages, enable the debugging flag in the Makefile.

    Using the SimpleFTP client.

        Usage:
            siftp <server name or IP> <port number>

        Info:
            Once connected to the server, the user will be presented with a
            password prompt. The default password is "ce150".

            Once authorized, the user will be presented with an application
            prompt, at which the command 'help' can be issued for details on
            supported commands.

    Using the SimpleFTP server.

        Usage:
            siftpd <starting directory> <port number>

        Info:
            Connected users will have their initial current working directory
            set to <starting directory>.

            The server should only be terminated when no users are connected
            in order to prevent stale sockets.


SPECIFICATION:

    The SimpleFTP protocol.

        The purpose of this protocol is to allow for file transfer between a
        file server and authorized clients.

        This is a request and response based protocol which is largely derived
        from the FTP protocol (RFC 959).

        The notion of request and response are implicit, and are not
        specifically tied to the client nor server. For example, in some cases
        the server sends a request to the client and expects a response.

    Message format.

        A message consists of a 'Verb' and a 'Parameter' (see Figure 1). The
        Verb specifies the subject, action, or intent of the message. The
        Parameter specifies information pertaining to the Verb. For a full
        list of Verbs and their use of the Parameter field, see file
        'siftp.h'.


            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                       _____________________________________________
                      | VERB           | PARAMETER                  |
                      |________________|____________________________|

                      |<------------- 1024 bytes ------------------>|

                      |<-- 4 bytes --->|<-------- 1020 bytes ------>|

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Figure 1. The message format. Note that these sizes are defined in
            the file <siftp.h> and can be changed.


        When sent over the network, the message is serialized into a string of
        contiguous bytes. The format of the serialized message is: the Verb
        followed by the Parameter. The sizes of these fields are defined in
        'siftp.h'.

    Command & Status dialogue.

        The client issues commands to the server and expects a response
        message containing the status of the command. This status is then used
        to decide the next action. For example if a client requests a file for
        download, the server can respond with a failed status (because it
        doesn't have read access to the requested file). Now the client
        doesn't have to wait for data because it knows of the command's
        status.

    Authentication dialogue.

        After the client establishes a TCP connection to the server, the
        client must be authorized before being allowed access to the files on
        the server.

        Client: I want to connect.
        Server: Identify yourself.
        Client: My user name is <name>.
        Server: Accepted/Denied.
        Client: My password is <pass>.
        Server: Accepted/Denied.
        - session established -

    File upload dialogue.

        Client: I want to upload a file named <filename>.
        Server: Proceed/Abort.
        Client: I am sending <length> number of bytes.
        Client: Here is some data.
            .
            .
            .
        Client: I have finished sending data.
        - transfer complete -

    File download dialogue.

        Client: I want to download a file named <filename>.
        Server: Proceed/Abort.
        Server: I am sending <length> number of bytes.
        Server: Here is some data.
            .
            .
            .
        Server: I have finished sending data.
        - transfer complete -

KNOWN PROBLEMS:

    In the SimpleFTP client, the application prompt initially is displayed
    twice.

    Stale sockets are present if the SimpleFTP server process is forcibly
    terminated while there are connected clients.

COMMENTS:

    Caveat: although I use the layer terminology of the OSI network model in
    describing the components of this program, they all really belong to OSI
    application layer.

    I have some network programming experience in Java, but this was the first
    time I worked on a network programming project in C.

    I originally planned to use the frame transmission strategies of using
    flags to delimit start and end of a frame [1], for performing Message
    transmissions. This model allows the transport layer to take care of
    breaking, say, a huge data file, into IP packets. However, I chose later
    on to use a fixed length message model, where this application took on the
    role of splitting, say, a huge data file into discrete Messages because it
    was easier to implement.

    I relied heavily on [2] for socket initialization in both server and
    client programs, as I was unfamiliar with BSD sockets.

REFERENCES (in MLA citation format):

    1. Tanenbaum, Andrew. Computer Networks. Fourth edition. New Delhi, India:
       Prentice Hall of India, 2003.

    2. Hall, Brian. "Beej's Guide to Network Programming". 8 October 2001. 22
       May 2004 <http://www.ecst.csuchico.edu/~beej/guide/net/>.