CS244A Review Session

1
CS244A Review Session

• Assignment 3/4 (STCP)?
• Friday, February 8, 2008
• Clay Collier
• (slides by William Chan)?

2
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)?
• Youll port your proxy from HW1 to speak STCP
• Your proxy will speak STCP to a regular HTTP
  server, routed through your router from HW2!

3
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!

4
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
server
mysocket
mysocket
transport
transport
network
network
5
What is STCP?

• TCP Lite (I Cant Believe Its 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

6
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 Ive 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

7
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_seqX is ACKed with th_ackX1
• 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 X1
• Successive ACKs may well acknowledge the same
  sequence number

8
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 familiaryou 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

9
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 dont have to deal with threads
  yourself...

10
(No Transcript)
11
STCP transport layer initiation
myconnect(), incoming SYN

• 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

transport_init()?
12
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!

13
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

14
STCP/application interaction

• Connection teardown (myclose)?
• Youll 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 dont have to worry about
  handling this
• An aside Include the mysocket descriptor in any
  debug messagesitll make your life easier in
  part (c)...

15
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 servicea partial read of a
  packet discards the unread remainder
• stcp_wait_for_event() notifies you of incoming
  packets
• You dont need to handle setting
  source/destination ports, or TCP checksum
• Stub code takes care of these aspects of
  transport layer responsibilities...

16
Part 3.aSTCP 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 youve finished this
• For testing and submitting code, we need (and
  accept) only transport.c
• No auxiliary files

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

18
General comments

• See Peterson Davie/RFC 793 for TCP FSM diagram
• Keep track of SYN_SENT, SYN_WAITING, etc.
• STCP state machine is slightly simplerno
  TIME_WAIT (doesnt 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
• Dont forget to use htonX()/ntohX() as
  appropriate in STCP header fields

19
General comments

• Efficiency
• Required Be sure not to wake up
  unnecessarily/sit in tight loops waiting for
  things to happen
• Dont 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, youll get a lot more out of the
  assignmentbut youll probably spend more time on
  it, too
• This would give you a taste of what a real TCP
  stack goes through... see the books description
  of mbufs if interested
• Dont worry about this if you dont care too
  muchcorrectness is much more important

20
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 cant get away with this for part (b)?
• Its worth the extra time to plan ahead rather
  than wasting effort
• Be aware of design changes/additions youll need
  to make to handle unreliable mode
• If for some reason you cant finish milestone (a)
  and/or (b) on time, you can submit them laterat
  a price, of course
• See grading guidelines in the assignment
  description

21
Assignment 4Putting it all together
22
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

23
Assignment 4 overview

• Topology setup
• Test against internal andexternal ftp servers
• Test with and without yourrouter
• Data flow in the system
• VNS network layerimplements usual
  IPfunctionality
• You dont have totouch this...

24
What do you need to do?

• Uses same Makefile, stub code as HW3
• Port proxy to mysock API
• Youll 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!

25
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

26
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
• Dont forget to test in unreliable mode! We
  will...
• When these work correctly, move on to your proxy

27
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 routers
  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!

28
TCP quirks

• You might find the following...
• Real TCP stacks will ignore packets without
  th_seq set, even if theyre valid ACKs
• Reduce chance of stray packets impacting
  connection
• Real TCP stacks always set th_ack whenever
  possible
• (STCP doesnt 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!
• Youll receive overlapping packets at the
  least...
• Theyre kinda picky tooyoull receive a TCP
  reset if you mess up sequence numbers...

29
General comments

• If you have a correct HW1-3, HW4 should be a
  piece of cake...
• But if you dont, it might not be...
• Try substituting our components to isolate the
  problem (see the assignment write-up for
  details)?
• If you really cant 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!)?

30
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

31
General debugging tips

• Dont 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 (youll 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

32
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!