Subject: First milestone See /home/westall/class/881net/assn1.f04 on the Sun net. (Also available via http://www.cs.clemson.edu/~westall/homepage.html) mw Subject: First quiz We will have the first quiz next Thursday. I have placed the old quizzes from last year in the directory. Subject: Milestone 1 I have created a directory for each of you in /local/jmw2/881/ms1 on the system jmw.cs.clemson.edu (which is a solaris system on our Sun network). Please turn in milestone 1 in your directory there. You will need to use scp to copy your files (or you will need to put your files in your home directory on the Sun network, log in to jmw, and then use cp to copy them over. mw Subject: Milestone 2 Add the following entry points to your protocol: struct proto ttp_prot = { name: "TTP", close: ttp_close, connect: ttp_connect, disconnect: ttp_disconnect, ioctl: 0, setsockopt: 0, getsockopt: 0, sendmsg: ttp_sendmsg, recvmsg: ttp_recvmsg, backlog_rcv: 0, hash: 0, unhash: ttp_unhash, get_port: ttp_getport, }; For this milestone you connect, disconnect, sendmsg, and recvmsg can be stubs.... For example: int ttp_sendmsg( struct sock *sk, struct msghdr *msg, int len) { return(len); } You will need to implement get_port, unhash, and close. /**/ /* Allocate a local port.. If snum is zero then */ /* any port will do. Otherwise try to allocate */ /* port snum (host byte order). */ int ttp_getport(struct sock *sk, unsigned short snum) /* Number of requested port or zero if */ /* any available port may be used */ { } This function needs to keep track of free and allocated ports. NO sharing of ports is allowed. It must return 0 on success and 1 on failure. On success the struct sock will be linked to a hash queue based upon port number and a reference to the struct sock will be held. On close the struct sock must be unlinked from the hash queue and the referenced will be released. This milestone not be due until we cover the corresponding material in UDP. Subject: Updated notes Three sections on UDP have been added. These should be read in the order: udpsock udpsend udpbind Subject: Updated notes In class Thursday we will begin the netfilter section. We will also have a quiz. Subject: Third milestone and notes update Let us attempt to have send working by next Monday Some updates have been made to the notes: netfilter has been partitioned into two components netfilter - first 10 pages of old netfilter devxmit - rest of old netfilter plus new stuff on freeing skbuffs and restarting the queue Next to be covered will be: udprecv devrecv Subject: Notes update and next quiz We finish iprecv2 and follow that with iprecv3 and udpdeliver. We will have a quiz on Thursday (when I am out of town) on the material covered since the last quiz. Subject: Quiz update The quiz is postponed until Thursday (when I again have to be out of town). Subject: Old quiz 4 I think I have located and replaced the original old quiz 4 with the correct one. Subject: Milestone 4 Let us try to be able to demo this on March 31 Milestone 4: In this milestone we will add a client/server connection facility to ttp. This will require a new header which is shown below. #define TTF_CONNECT 1 /* Connect request or connect ACK */ #define TTF_ACK 2 /* ACK number is valid */ #define TTF_CLOSE 4 /* Close request or close ACK */ #define TTF_RESET 8 /* Abort a connection */ typedef struct ttp_hdr { unsigned short sport; /* src and dest ports */ unsigned short dport; unsigned short len; /* packet length */ unsigned short sack; unsigned char flags; /* See bit defs above */ unsigned char seq; /* PACKET seq # */ unsigned char ack; /* Ack number */ unsigned char pad; /* Not used */ } ttp_hdr; The connection model that we will use is somewhat like that of TCP but is (hopefully) simpler and based upon a client/server model. Server Connection states are: Closed - Listen - Connect ACK - Established - Closed Client Connection states are: Closed - Connect - Established - Closing - Closed ONLY the client system can initiate a connection or a close. Connect requests should be retried up to 6 times with a 5 second delay between retries. The server enters the Established state upon receiving the first data packet (Connect flag == 0). The client enters the Established state upon receiving a Connect/Ack. There should be no ACK for a close. An unexpected packet in any state should trigger a Reset. Receipt of a Reset should immediately abort a connection. Ack number should be NEXT packet expected. Subject: Class today I've made another pass over the default selection logic which is available in updated notes. When we finish that we will take a quick tour of input routing. (routein.pdf) Subject: Demos today I've put a couple of (untested) programs in the code subdirectory that can be used in testing the connection facility. (client.c and server.c) Subject: permissions please try again Subject: Exam We will convene at 9:00 am on Tuesday for the exam. Subject: Demo We will meet in the lab at 11:00 for demos. Here is a example of the proper use of flags/acks/seqs Flags Ack# Seq# Conn_req --> CA ? 37 <-- Conn Ack CA 38 11 Data ---> A 12 38 <-- Ack A 39 12 Data ---> A 12 39 <-- Ack A 40 12 <-- Data A 40 12 ACK ---> A 13 39 Subject: Arrrrggghh A connection request should carry the Connect bit but NOT the Ack bit. Sorry about that.