Due: April 29, 200

You may discuss this assignment with other students in the class, but the work you submit must be your own.  In particular, all programming efforts must be conducted individually and all code must be original, though you are welcome to use your own code from previous assignments in other courses.

Overview

This assignment augments SSL/TLS for use with migrating applications. The idea is simple: design a system whereby a migrating application, a simple text transfer in our case, is able to maintain an SSL/TLS session with a server. A migrating application, for our purposes, is one which terminates on one host only to resume where it left off on another host. Self-certified certificates should be used for this project.

Project Details

Server

Your server's only purpose is to transfer text files using SSL. However, since it supports migrating applications it must be able to terminate or "pause" a session to be resumed within a few minutes. Following a pause in the transmission, the server must wait, say, a minute or so for the session to be resumed by a client. This one-minute interval is more than enough time for an application to "migrate" itself over to another host and resume the transfer. If the transfer does not resume within a couple of minutes, the server should assume that something is amiss, and delete the session info (so it will not be possible to resume it after that). Keep in mind that when the server resumes a transfer with the application on a different host, it is responsible for addressing new packets to the new host on which the client resides (this isn't so bad since every incoming packet has a return address & port number).

Also note that if a terminate/pause message has been received and the file has not been completely sent, the server cannot close the file input until that one-minute interval has passed, for it will likely have to resume the transfer where it left off. SSL requires TCP which is a reliable transmission protocol; hence you are not required to implement any sort of acknowledgment system or guarantee that packets were received properly.

Client 1

The first client is responsible for initiating a secure session with the server. Once a session is open the client should accept part of the file to be transferred, say, the first ~10K. The information received from the server should be stored in a file called "out1". After 10K has been transferred, the client should decide to pause transmission to "migrate" the application to another host. To that end, the client sends a "pause" message.

Once the session is paused, client1 must open a secure session with client2 and hand off all information required to resume the SSL session. The aggregate of this data is called the context. It is your job to determine what information is necessary, compile it, and transfer it in a manner that is useful to client2.

After the context has been transferred, client1 will terminate gracefully.

Client 2

This client2 will initially wait for a request to connect from client1. Once a secure session has been established client2 will accept all information necessary to reconstruct the context required to resume the SSL session with the server (initiated as above by client1). When the session is resumed, client2 will accept the remainder of the transfer from the server, saving it to the file called "out2", close the file and then await a new session from another client.

Implementation & Testing

See /usr/j2* directories on csa and in particular the README.html files there.

Good reference: http://java.sun.com/products/jsse/ and tons of other resources on the web.

Starting your programs

• The server will require two command line arguments,
  1. the port number
  2. the name of the file to transfer

  If the server cannot bind to the port or find the file, the program should exit.

• Client 1 will require the following arguments in the following order,
  1. the port number you wish to run on
  2. the name of the host on which the server is located
  3. the server port number
  4. the name of the host on which client 2 is located
  5. client 2's port number

  If Client 1 cannot bind to its port, it should exit gracefully.

• Client 2 will require the following arguments in the following order,
  1. the port number you wish to run on
  2. the name of the host on which the server is located
  3. the server port number

  If Client 1 cannot bind to its port, it should exit gracefully.

Notes

• The idea behind this assignment is not difficult but there are many small details to worry about. It will help to really think about what is required, what is involved, and how to go about accomplishing the task at hand, and to develop a plan of attack ahead of time (ie. pen-and-paper at least a rough solution).
• Modification of the libraries is inevitable for this assignment as there is no support for retrieval of the information necessary to build a context. You will need to spend some time to really understand hierarchies and dependencies. You will also need to implement get() and set() functions to retrieve and modify, respectively, members of the context.
• If properly designed, the source code of client 1 and client 2 will be identical. This isn't necessary but may make life easier, not to mention is simply better practice.
• Consider that the clients in our SSL for migrating apps are also servers since they wait for session requests. This means that any client which must receive a migrating application as well as resume a transfer will require two (2) contexts. For example, client 2 will require one context to retrieve information from client 1, and another separate context (which it builds from information supplied by client 1) to resume a transfer from the server.
• The text is a good source, use it. A lot of the code for this assignment can be plucked from example code in the SSL text.

Answers to (old) frequently asked questions:

>... have problems sending the context values. How
> can we transfer context from one client to another. We were able to do it
> with integer and string values, but what about different pointers (to
> different functions or structures)? How do we deal with them?

Need to allocate space for the structure, and then insert fields in.
Example:

You want to send header info data. This is how you would do it:
char buf[sizeof(struct udpiphdr) + 100], *ptr

ptr= buf + sizeof(struct udpiphdr); //leave space for header
*((u_short *) ptr) = htons(1234); //identification
ptr+=2;
*((u_short *) ptr) = htons(0x0); //flags

And so on for all the fields

nbytes = 36; //size of fields
write(buf,nbytes);

Submission and Grading Guidelines

Electronically submit the code and Makefile (or some compile & link script) for the code that you write by using "gsubmit". Keep all files in a directory called “pa2” and submit that directory with all necessary contents. Your code will be run and tested on the csa machines -- make absolutely sure that your program compiles and runs correctly on csa as there are often portability issues if you develop your code on another platform, and these may take considerable time to resolve.

Academic Conduct Reminder

Submitting part or all of another person's assignment (or leveraging another person's work to produce your own submission) is an act of plagiarism. Submissions will be checked for originality by hand and by a program checker -- please do not jeopardize your academic standing by taking chances in completing this assignment. If using publicly available code as a model for your own, please include a reference.  Lastly, come see me if you have any questions about where I (and the college) draw the line regarding acceptable levels of collaboration.

                                                                            (Thanks to John Byers for help in writing this assignment).