Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS244A Review Session #3 Assignment #2 (STCP) Friday, January 24, 2003 Matthew Holliman.

Similar presentations

Presentation on theme: "CS244A Review Session #3 Assignment #2 (STCP) Friday, January 24, 2003 Matthew Holliman."— Presentation transcript:

1 CS244A Review Session #3 Assignment #2 (STCP) Friday, January 24, 2003 Matthew Holliman

2 Assignment overview Write your own reliable transport layer Three parts: –Basic STCP functionality Delivery over reliable network –Connection setup/teardown, windows, ACKs… –No dropped packets, reordering, retransmissions Due one week from today –Support missequenced/lost packets Reliable delivery over unreliable network –Retransmissions (timeouts, Go-back N), buffering… Due in a fortnight (Fri, Feb 7 th ) –FTP client from HW#1 running over STCP Modify your HW#1 or use our object files Due Wed, Feb 12 th Get started early!

3 Assignment overview Client/server (client.c, server.c) –File download application “Mysocket” layer (mysock.c) –Replacement for socket API (myopen, myread, etc.) STCP (transport.c) –Transport layer: You fill this in! Network layer (network.c) –Simulates random packet loss, delay, duplication –network_send(), network_recv()—datagram service used by STCP client mysocket transport network server mysocket transport network

4 What is STCP? TCP Lite –Simplified connection setup Two-way handshake –No piggybacking of data with acknowledgement packets –No congestion control –No slow-start, fast retransmissions, delayed ACKs, etc. Still provides reliable, connection-based, byte- oriented transport between two endpoints –Flow control (sliding sender/receiver window) –Go-back N –Retransmissions

5 STCP packets Simplified version of TCP segments –SYN packet: start a connection –ACK packet: acknowledge reception of data (next seq) No data payload permitted in STCP SYN-ACK: passive side completes connection –FIN packet: end a connection FIN-ACK: passive side closed connection –Data packet: Any packet without these flags set –SYN/data packets: sequence numbers –No advertised window

6 STCP model Each side of connection: two processes –Parent (application/mysocket layer) –Child (your STCP implementation/network layer) Why this model? –Simulates real O/S implementation User-level socket library interfaces to kernel functionality Network data arrival is asynchronous Protocol stack is idle until packet arrives –H/W interrupt  O/S context switch, kernel packet processing, data passed up stack to app –STCP implementation can sleep until an “interesting” event happens Timeout, packet arrival, etc.

7 STCP model transport implementation network transport interface mysocket client transport implementation network transport interface mysocket server Parent Child

8 STCP transport layer initiation transport_init() creates two socket pairs, forks; parent blocks until connected –In STCP, a SYN received from peer by child Parent/child communicate via local sockets (a la pipe) –syn_sd[]—notify parent of connection completion –data_sd[]—pass data between app/transport layer –Application end of data pipe returned by transport_init() myconnect(), myaccept() transport_init() Parent (app) Child (transport) syn_sd[0] (syn pipe) data_sd[0] (data pipe) syn_sd[1] data_sd[1] syn_sd[0] data_sd[0] syn_sd[1] (syn pipe) data_sd[1] (data pipe) comm_sd (peer socket) fork IPC Data pipe Syn pipe

9 STCP IPC details Forking, IPC is provided already in transport.c –You shouldn’t need to touch much of transport_init(), except to Add your SYN/SYN-ACK handling Change/add the transport layer state setup as needed –Sockets created in transport_init() (using localsocketpair()) before forking Descriptors valid in both parent/child processes Syn_sd[] used only for connection setup Data_sd[] used for all data sent between application and transport layer Only one of each socket is used in parent/child to communicate, a la pipe/FIFO –transport_init() closes unneeded sockets in parent and child

10 STCP/application interaction Connection establishment (myconnect, myaccept) –Application blocks until SYN received STCP wakes up blocked parent process using “syn pipe” –Use network_peer_name(&peeraddr…), write to its syn_sd socket syn_sd is finished with at this point –See select(3c), poll(2) Data read/write (myread, mywrite) –Application reads from/writes to its end of the “data pipe” (the socket returned by transport_init() in the parent process) –STCP writes to/reads from its end of the “data pipe” Whenever data is available (from app or peer) and you have space in your window Just assume data written to application has been read

11 STCP/application interaction Connection teardown (myclose) –Application closes stream socket returned by transport_init() –Pay attention to delivery semantics in assignment handout Parent blocks in transport_close(), waiting for child to exit Child waits for all outstanding data to be ACKed before sending FIN Child process exits on FIN-ACK, unblocking parent –Passive end closes connection immediately on receiving FIN Multiple connections –A unique child process is forked by transport_init(), so you don’t have to worry about session demultiplexing

12 STCP main control loop Stub transport.c talks about “callbacks” –You can ignore this if it’s confusing (I did) –You will probably want to split out functionality for handling data from the app (e.g., transport_appl_io) and functionality for handling data from the peer (e.g., transport_sock_io) –This is all handled in the child process by your transport layer Main loop repeatedly waits for event on application socket (local_data_sd), peer socket (comm_sd), timeout (in part B onwards) –Select/poll to see which event happened –Be sure not to wake up on application socket unless your sender window is open!

13 Select Online information –man –s 3c select Looks in section 3c of manual (C library) Also useful: section 2 (system calls), 3socket (socket calls) Select semantics –Wait for file descriptor(s) to become readable/writable/error state –select(fd_range, &readfds, &writefds, &errfds, &timeout) fd_range—range of file descriptors to test (0..fd_range-1) readfs (writefds/errfds)—description of file descriptors of interest timeout—time interval for which select() blocks if no socket becomes readable/writable/error state (NULL  infinite) fd_set readfds; FD_ZERO(&readfds); FD_SET(my_sock_fd, &readfds); … switch (select(my_sock_fd+1, &readfs, NULL, NULL, &timeout)) {… Be careful! These are common problem areas…

14 Poll “Newer” system call –More efficient kernel implementation than select –No need to scan through all open file descriptors –You explicitly specify the descriptors of interest Poll semantics –poll(struct pollfd fds[], int nfds, int timeout); –pollfd structure contains file descriptor, events of interest struct pollfd fds[] = { { my_socket, POLLIN, 0 } }; switch (poll(fds, sizeof(fds)/sizeof(fds[0]), timeout_interval) { …

15 Part 2.a—STCP in reliable mode Network layer refrains from any mischief All packets delivered in sequence, no losses You implement connection setup/teardown, acknowledgements, send/receive windows Client/server pair should be able to download files after you’ve finished this For testing and submitting code, we need (and accept) only transport.c –No auxiliary files

16 1000 Client: mywrite(…, 2048) Part 2.a—STCP in reliable mode Window example –Other side received through seq #999, responded with ACK for seq #1000 –We’ve sent through seq #2999 –Sender window is = 1072 bytes Last seq # acked … Seq # 3000 Seq # 4072 STCP ACK packet th_ack=

17 Part 2.b—STCP in unreliable mode Network layer becomes obnoxious –Packets reordered, dropped, duplicated –See network_send() in network.c You must handle retransmissions, timeouts, Go-back N, buffering of data, … –No exponential back-off –Minimum RTT estimate is 20 ms –Five retransmissions of any segment –Careful about packets crossing ends of receive window Client, server pair should now work with –U flags Your modified transport.c is the only file needed (and accepted) for testing and the final submission

18 Part 2.c—STCP-based ftpcopy You can either modify your HW#1 to use STCP, or you can use the provided object files (libftpcopy.a etc.) –Should just be a few minutes of work –Change the provided Makefile as needed –If linking your transport layer against the STCP-talking libftpd.a, there is a caveat… Don’t write anything to stdout! Disable debugging messages, or write to stderr –Another caveat… libftpcopy.a works only against localhost

19 General comments See Peterson & Davie for TCP FSM diagram –Keep track of SYN_SENT, SYN_WAITING, etc. –STCP state machine is simpler Network layer uses UDP datagrams –Treat it like an IP implementation –Packet-oriented rather than byte-oriented service –Be sure to read the maximum length datagram! Unread bytes in a datagram are discarded by recv() Portability –Don’t forget to use htonX()/ntohX() as appropriate in STCP header fields

20 General comments Efficiency –Required: Be sure not to wake up unnecessarily/sit in tight loops waiting for things to happen Use select(), poll() appropriately Don’t select() on app socket unless you can really send data –Pedantic (optional, but encouraged): If you can avoid unnecessary memcpy()s, you’ll get a lot more out of the assignment—but you’ll probably spend more time on it, too See the book’s description of mbufs if interested Don’t worry about this if you don’t care too much— correctness is more important

21 General comments Yes, for part (a), the lazy STCP implementer could just send data directly to/from the app, no need to buffer –You still need to pay attention to the windows But you can’t get away with this for part (b) –It’s worth the extra time to plan ahead rather than wasting effort –Be aware of design changes/additions you’ll need to make to handle unreliable mode

22 Debugging Don’t forget to Purify! –It can save you a lot of time on this assignment –Bad select() calls, invalid pointers in network_recv(), can cause some mysterious behaviour in your code gdb –Normal approach is to place ‘set follow-fork-mode child’ in your.gdbinit –This doesn’t work for me now (?!) –Ugly hack: add sleep(N) in your child after the fork(), run the client/server pair outside of gdb, do ‘ps’ and attach to the child process (larger PID) of interest with ‘gdb {server|client} PID’ –If you have better ideas, please post them to the newsgroup!

23 General nagging Start early and test often –This assignment is trickier than it looks! The earlier you can get to part (b), the better… –This will probably be the toughest two week stretch of the quarter (for everyone…) Please remember to submit to the right TA! –Steve received only five submissions for HW#1; 26 people incorrectly submitted to Guido or me, despite having been reassigned!

Download ppt "CS244A Review Session #3 Assignment #2 (STCP) Friday, January 24, 2003 Matthew Holliman."

Similar presentations

Ads by Google