Project 1.3: The Home Stretch

CS233/333 - Networks and Distributed Systems
Fall, 1999.

Final Due Date: Tuesday, November 2, 11:59 p.m.

1. Overview

Well, now you should be in the home stretch with the project. To finish the project, you need to implement both a datagram and stream based network interface. The datagram interface (UDP) should have been completed already. This part of the project will primarily involve the stream based protocol (TCP).

2. TCP

To finish the project, you must implement a stream-based protocol similiar in functionality to TCP. However, given the complexity of TCP you are free to implement your protocol in any manner you see fit as long as it is layered on top of IP. In other words, keep it as simple as possible.

Your stream-based protocol should work roughly as follows:

Define a handler function that is used to process incoming packets. Your handler function should be registered using the ip.register_protocol() function as follows:
```
import proto
import ip

...
ip.register_protocol(proto.IP_CS333TCP, tcp_handler)
```
Please note that the protocol number for your protocol should be proto.IP_CS333TCP, not the protocol number of 6 used for normal TCP.
Create a class TCP_socket that defines a socket structure for your TCP protocol. This socket should minimally have the following attributes:
- A port number (the port to which the socket is bound).
- A state variable indicating the operational state of the socket (closed, connected, listening, etc...).
- An incoming data queue. This is where the handler function will place data as it arrives.
- Methods for binding, accepting, listening, connecting, closing, reading, and writing.
In addition, your module must maintain a table of port numbers to sockets. When your handler function decodes the TCP header, it will look at the target port number and perform a lookup in this table. If no matching port is found, the incoming packet is discarded. Note: the port numbers used for TCP and UDP are isolated (i.e., it is not an error for a UDP server and a TCP server to have the same port number).

3. The socket interface

Continuing your work from last time, finish the implementation of the lsock.py file so that it defines the following functions:

socket(family,proto). Create a new socket object. family is the address family and proto is the protocol. Your implementation should look at these values and create a socket of appropriate type. For this project, proto.AF_CS333 is the only recognized address family. proto.SOCK_DGRAM specifies a datagram protocol, and proto.SOCK_STREAM specifies a stream based protocol like TCP.
bind(s,port). Binds socket s to a port number. When called, this function should examine any internal tables to see if the port number is already in use. If so, an error is generated. Otherwise, the socket's address should be set to the given port number and an entry to the socket placed in the internal port table. After this call has been completed, any data addressed to this port should be placed in the socket's internal data queue.
listen(s,backlog). Put a socket s into listen mode. backlog specifies the maximum number of pending connections. Once this call has been made, a socket should start accepting new connections. This function only applies to sockets of type SOCK_STREAM.
accept(s). Accepts a new connection on socket s. The function blocks until a connection is received. When a connection is received, a new socket object should be returned on which data transmission will occur. When creating this new socket, it should be bound to any unused port number.
connect(s,addr). Connects to machine addr where addr is a tuple of the form (ipaddr,port) specifying the address of the remote machine. For example:
```
connect(s,("nlab-1",8888))
```
On success, the function should return nothing. Otherwise, it should print an error if a connection could not be established for some reason.
read(s,maxsize). Read at most maxsize bytes from socket s. The read operation should examine the sockets incoming data queue. If it is non-empty, the function should return immediately with data (not exceeding the maximum length). If the queue is empty, the function should block until data arrives (when the underlying protocol handler receives a datagram and places it in the socket's queue). For SOCK_STREAM connections, repeated called to read() should return pieces of the incoming byte stream without any data loss. Furthermore, in this case, the function should always return if incoming data is available (even if the data is less than the maximum requested size). For datagrams (SOCK_DGRAM), the function returns the first maxsize bytes of any incoming datagram. For simplicity any remaining bytes of a datagram should be discarded.
write(s,data). Write data to the socket s. The function should block until all of the data has been successful sent. Furthermore, the function should be able to successfully send data of arbitrary length. This function only applies to stream-based sockets (SOCK_STREAM). Use sendto() for SOCK_DGRAM sockets. Returns the number of bytes sent on success.
sendto(s,data,addr). Sends a datagram data to the socket s. addr is a tuple of the form (ipaddr, port) that specifies the address of the remote machine. For example:
```
sendto(s,"Hello",("192.168.69.4",1234))
```
This function blocks until the packet is successfully sent. If the packet can not be sent for some reason (unknown host), an error should be returned. Otherwise, the actual number of bytes sent should be returned.
getpeername(s). Returns the address of the remote machine as a tuple (ipaddr,port). In the case of UDP, this returns the address of the machine that sent the last datagram read using the read() function.
close(s). Closes the socket. This should clear the socket's address, incoming data queue, and remove the socket's port number from any internal port tables. Once closed, sockets should not be reused.

4. Testing

Your code will be tested with a number of simple networked programs that only make use of the 'lsock' module. That is, they will create some sockets and try to communicate with each other in various ways. Because the internals will not be tested explicitly, you have complete freedom in terms of how you actually implement IP, UDP, and TCP. Tests will be made available on mailing list.

5. General comments

This last part of the project may be extremely difficult if you have not made good progress on earlier parts of the project. Here are the general grading criteria:

At a minimum, you must implement a working version of the UDP protocol to get a passing grade.
To get an A, you will need to have some sort of working stream based network protocol. In other words, I need to be able to run a variety of network based programs such as web-servers and other services on it.
Your implementation does not have to be completely robust. In particular, the performance of your implementation is likely to be pretty terrible and the error correction and recovery fragile at best. This is fine.

Please come and see me if you run into trouble.