Unformatted text preview:

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32CS244A Review SessionAssignment #3/4 (STCP)Friday, February 8, 2008Clay Collier(slides by William Chan)Assignment overview•Assignment #3 (STCP)–Write your own reliable transport layer•Runs over our simulated datagram layer•Reliable and unreliable network layer modes •Assignment #4 (Putting it all together)–Show that your transport layer interoperates with real TCP•Runs over raw IP (via VNS)•You’ll port your proxy from HW1 to speak STCP•Your proxy will speak STCP to a regular HTTP server, routed through your router from HW2!Assignment #3 overview•Write your own reliable transport layer•Two milestones:–Basic STCP functionality•Delivery over reliable network–Connection setup/teardown, windows, ACKs…–No dropped packets, reordering, retransmissions–Support missequenced/lost/duplicate packets•Reliable delivery over unreliable network–Retransmissions (timeouts, Go-back N), buffering…•Get started early!Assignment #3 overview•Client/server (client.c, server.c)–A simple 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 (stcp_api.c, network*.c)–Simulates random packet loss, delay, duplication–stcp_network_send(), stcp_network_recv() — datagram service used by STCPclientmysockettransportnetworkservermysockettransportnetworkWhat is STCP?•TCP Lite (“I Can’t Believe It’s Not TCP”)–No congestion control (slow-start, cwnd, etc.)–No fast retransmissions, delayed ACKs, etc.–No resets, sequence number wraparound, TIME_WAIT, etc.•Still provides reliable, connection-based, byte-oriented transport between two endpoints–Flow control (sliding sender/receiver window)–Go-back N–Acknowledgments, timeouts, and retransmissions•Implements minimum functionality to talk to real TCP–Three-way handshake–Four-way connection terminationSTCP packets•Usual TCP segment format–SYN packet: start a connection–ACK packet: acknowledge reception of data (next seq)•SYN-ACK: passive side responds to connection request–FIN packet: I’ve finished sending data•Even after sending the FIN, data may continue arriving from the other side, until it too sends a FIN•When both sides have sent FINs and received ACKs (or reached the retransmission limit), the connection is torn down–Data packet: Any packet with a sequence number and non-zero payload length (options excluded)–All packets have a sequence number associated with themSequence numbers and ACKs•th_seq is sequence number associated with first byte of payload–SYN and FIN occupy one byte of sequence space•SYN, FIN with th_seq=X is ACKed with th_ack=X+1–An “empty” ACK packet has a th_seq of whatever the next unsent sequence number would be...•For compatibility with TCP, th_ack is always set, once the connection is established–Next sequence number expected from peer•i.e. if you receive up through sequence number X, you ACK with X+1–Successive ACKs may well acknowledge the same sequence numberA quick tour of the stub code•We provide the mysocket and network layers–You fill in the transport layer (transport.c)•The source layout...–stcp_api.c, stcp_api.h: transport layer interfaces to the application/network layers•These are the most important interfaces with which to get familiar—you must use these in your solution–mysock_api.c, mysock.c, connection_demux.c, tcp_sum.c: socket layer API/implementation–network*.c: network layer implementation–client.c, server.c: client/server applications for HW3–echo_client_main.c, echo_server_main.c: echo server/client for HW4STCP model•Each new STCP connection spawns a thread for your transport layer–Main application thread invokes mysocket functions (myread, mywrite, myclose)–Transport layer thread sits in an event-driven loop•Why this model?–Simple approximation to 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.–Note: You don’t have to deal with threads yourself...STCP modeltransportimplementationnetworktransportinterfacemysocketclienttransportimplementationtransportinterfacemysocketserverApp threadSTCP threadnetworkTCP TCPVNS (IP) VNS (IP)STCP transport layer initiation•transport_init() starts in a new thread–Application blocks in myconnect(), myaccept() until connected–When transport_init() eventually returns, the connection is considered closed–transport_init() should kick off the main event loop•App thread/STCP thread communicate via interfaces provided in stcp_api.cmyconnect(), incoming SYNtransport_init()STCP main event loop•Main event loop in transport layer repeatedly waits for...–An application event (new data to send, close request)–Incoming packet(s) from peer–Timeout (in milestone B onwards)•How to implement this?–stcp_wait_for_event()–Be sure not to wake up on an application write unless your sender window is open!STCP/application interaction•Connection establishment (myconnect, myaccept)–Application blocks until SYN is acknowledged•STCP wakes up the blocked application thread–stcp_unblock_application()•Writing data: mywrite()–Application writes to mysocket in application thread–STCP reads from the app with stcp_app_recv()•Note: Only when you can actually send data!•Reading data: myread()–Application reads from mysocket in application thread–When you can reassemble stream from peer, STCP notifies app/passes data up: stcp_app_send(), stcp_fin_received()•Just assume data written to application has been read•stcp_app_send(), stcp_app_recv() behave like a stream/pipeSTCP/application interaction•Connection teardown (myclose)–You’ll receive a “close requested” event from stcp_wait_for_event()–Pay attention to semantics in assignment handout/RFC•Parent blocks in myclose(), waiting for STCP thread to exit•Be aware


View Full Document

Stanford CS 244a - Study Notes

Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?