CS244A Review Session

Assignment #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 STCP

client

mysocket

transport

network

server

mysocket

transport

network

What 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 termination

STCP 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 them

Sequence 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 number

A 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 HW4

STCP 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 model

transportimplementation

network

transportinterface

mysocket

client

transportimplementation

transportinterface

mysocket

serverApp thread

STCP thread

networkTCP 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.c

myconnect(), incoming SYN

transport_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/pipe

STCP/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 of subtleties in implementing 4-way termination

• Multiple connections– A new transport layer thread is spawned per

connection• The stub code takes care of session demultiplexing--

you don’t have to worry about handling this• An aside: Include the mysocket descriptor in any

debug messages—it’ll make your life easier in part (c)...

STCP/peer interaction

• You will use stcp_network_send(), stcp_network_recv() to send/receive datagrams to/from the peer– Unreliability is simulated by our network layer

(network.c)– This is a datagram service—a partial read of a

packet discards the unread remainder– stcp_wait_for_event() notifies you of incoming

packets

• You don’t need to handle setting source/destination ports, or TCP checksum– Stub code takes care of these aspects of transport

layer responsibilities...

Part 3.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

Part 3.b—STCP in unreliable mode

• Network layer becomes obnoxious– Packets reordered, dropped, duplicated– See network.c for how this is done

• You must handle retransmissions, timeouts, Go-back N, buffering of data, …– No exponential back-off– Minimum RTT estimate is 100 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

General comments

• See Peterson & Davie/RFC 793 for TCP FSM diagram– Keep track of SYN_SENT, SYN_WAITING, etc.– STCP state machine is slightly simpler—no

TIME_WAIT (doesn’t make sense for us)

• Network layer simulates a datagram service– 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 stcp_network_recv()

• Portability– Don’t forget to use htonX()/ntohX() as appropriate in

STCP header fields

General comments

• Efficiency– Required: Be sure not to wake up unnecessarily/sit

in tight loops waiting for things to happen• Don’t wake up on application data unless you can

really send some data– Pedantic (optional, but encouraged): If you can

avoid unnecessary memcpy()s in your buffer management, you’ll get a lot more out of the assignment—but you’ll probably spend more time on it, too

• This would give you a taste of what a real TCP stack goes through... see the book’s description of mbufs if interested

• Don’t worry about this if you don’t care too much—correctness is much more important

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

• If for some reason you can’t finish milestone (a) and/or (b) on time, you can submit them later—at a price, of course– See grading guidelines in the assignment

description

Assignment #4:Putting it all together

Assignment #4 overview

• Your STCP will (or at least, should!) interoperate with real TCP– We provide a VNS-based IP layer

• Replaces the simulated datagram layer we used in HW3

– You should have little new code to write• Goal: Your web proxy will run over your transport

layer, with the packets routed through your router, to places like www.google.com

Assignment #4 overview

• Topology setup– Test against internal and

external ftp servers– Test with and without your

router

• Data flow in the system– VNS network layer

implements usual IPfunctionality

– You don’t have totouch this...

What do you need to do?

• Uses same Makefile, stub code as HW3

• Port proxy to mysock API

• You’ll need to modify your proxy to support the usual VNS client options– See echo_client_main.c, echo_server_main.c

• Since your proxy runs on a VNS node, you may need a few modifications– mylocalip() gives you your virtual IP address

• Now... debug!

STCP-based web proxy

• Modify your HW1 to use STCP– Should just be a few minutes of work

• Caveat: Our mysocket layer does not support things like select() or recv()

– Change the provided Makefile as needed

• Include your transport.c, README (short, please!), and any *.c, *.h files needed to build your proxy

Debugging your transport layer

• It may be easiest to start with an echo server/client– Canonical network debugging tools– Makefile builds stcp_echo_server, stcp_echo_client

• These should be compatible with regular telnet/echo service respectively– stcp_echo_server –t topoid –v vhost; telnet vhost 7 should access an echo server on your virtual host

– stcp_echo_client –t topoid –v vhost klamath should access the echo service on klamath

• Be sure to use ‘-l’ to log packets for analysis with tcpdump/ethereal

• Don’t forget to test in unreliable mode! We will...

• When these work correctly, move on to your proxy

Debugging your proxy

• Multiple connections (i.e. multiple threads) make this more challenging debugging environment

• Without your router...– When debugging the proxy, you might find it

easiest initially to connect it to your router’s position on the topology

• With your router...– When this is working, you can try connecting both

your router and your proxy– Be sure to set up the routing table correctly for

both the virtual host and the virtual router important!

• Again, be sure to log packets and test it in unreliable mode!

TCP quirks

• You might find the following...– Real TCP stacks will ignore packets without th_seq set,

even if they’re valid ACKs• Reduce chance of stray packets impacting connection

– Real TCP stacks always set th_ack whenever possible• (STCP doesn’t strictly require this, but the RFC does)• Many firewalls drop FIN packets without ACK set

– Old `stealth port scan’ technique (send SYN, recv SYN-ACK, send FIN w/out ACK)

• Reduce chance of stray packets impacting connection– Real TCP stacks are buggy!

• You’ll receive overlapping packets at the least...– They’re kinda picky too—you’ll receive a TCP reset if

you mess up sequence numbers...

General comments

• If you have a correct HW1-3, HW4 should be a piece of cake...– But if you don’t, it might not be...

• Try substituting our components to isolate the problem (see the assignment write-up for details)

– If you really can’t get something working• You may use 1 of our binaries at no cost• You may use 2 of our binaries 50% penalty• If you have to use 3 of our binaries... Guaranteed

A+ (actually, no credit)• Be sure to specify in your README if you choose

one of these options (and make sure that your Makefile does what you expect before you submit!)

Assignment #4 deliverables

• Your source structure should look as follows:– Makefile, transport.c, *.c, *.h – STCP/proxy

implementation– sr_src/{Makefile,*.c,*.h} – your router

implementation– README – short description of changes

you had to make to get this working, things that made you go hmm...

• Submit as usual– See HW4 description for details

General debugging tips

• Don’t forget Valgrind!– It can save you a lot of time on these

assignments

• gdb– If you assert() or crash in your transport layer, it

should use your thread as the current context• You can do ‘info threads’ to show all threads in the

program (you’ll see a bunch)• ‘thread N’ sets the current thread context to that

of N, where the usual ‘bt’, ‘n’ etc. work

• Make liberal use of assert() for sanity checks• Logging

– When testing compatibility against real TCP in HW4, be sure to use the ‘-l’ functionality in your client to get a tcpdump trace

General nagging

• Start early and test often– These assignments can be trickier than they

look!• The earlier you can get to milestone 3(b), the

better…

– This will probably be the toughest two week stretch of the quarter (for everyone…)

• A final reminder...– When you get frustrated over the next couple of

weeks, stay patient--these assignments are really cool when you get them working!

• Have fun!