Outline: x-kernel details

• Exam Review
• Protocols
• Sessions
• Open and Close
• Push
• Pop and Demux
• Message primitives
• Events
• Working with the x-kernel

Exam Review

1. Fixed Size
2. Network (part of IP) or Transport (above IP)
3. ATM connections involve some/all intermediate switches, TCP connnections only involve the end systems
4. (a): different network, send to default router (b): same network, send directly to host
5. 1.2.3.4, 9 hops, 5.6.7.8; 9.0.1.2, 4/infinite hops, 5.6.7.8;
6. 1. limited time is needed to make TCP's sliding window reliable
   2. limited hops is needed to limit resource (bandwidth) consumption
7. discard the packet (NEVER block in an interrupt handler)
8. 1s to send packet, 1s to get ack, 500b/s
9. 1000b/s * 2s (from start of packet send to ack) = 2,000 bit windows
10. 1 s = 1,000 ms = 1,000,000 u s (1 u s = 1 us)
    • 100 u s S transmission delay
    • 10 u s S to R1 propagation delay
    • 10 u s R1 routing delay
    • 300 ms R1 queueing delay
    • 100 ms R1 transmission delay
    • 1 ms R1 to R2 transmission delay
    • 10 u s R2 routing delay
    • 100 u s R2 transmission delay
    • 10 u s R2 to D propagation delay
    total is 0.40124 s
11. • same header
    • transmit when ready
    • hubs don't work (or are equivalent to switches)
    • switches work the same
    • should be faster (more wires, no collisions, no backoff),
    • reliability is similar or marginally better because of no collisions.
    • note: many people added ACKs, or connections, or TTL. Why????

x-kernel: the big picture

• because of the layering costs of downcalls, most implementations are not layered: they are monolithic
• a monolithic implementation is not modular, it is hard to split into pieces to be tested independently
• lack of modularity makes maintenance difficult and expensive
• the x-kernel microprotocols is a building block that can be re-layered as desired and tested independently
• the uniform protocol interface makes sure all building blocks will fit -- does not guarantee they will "work" (whatever that means)

Protocols and Sessions

• a protocol is a piece of code that is statically composed with other protocols
• a protocol must provide function such as:
  • open a session
  • openEnable to passively open a session, and openDone to accept such a session
  • close to close a session
• a session is a dynamic object, created as a result of one of the open calls
• protocol functions called on open sessions:
  • push outgoing data down a protocol stack
  • pop received data up a protocol stack
  • demux: called to select an appropriate session in this protocol for received data

Open

• A session can be actively opened by calling xOpen. Active open takes a set of participants and connects to them.
• Sessions can also be passively opened by calling xOpenEnable. This will create a session if and when a remote system does an active open.
• Whenever a connection is passively opened, the lower protocol calls xOpenDone, which calls the higher level protocol's {\tt openDone} procedure. xOpenDone is an upcall.
• class question: how can connectionless protocols (e.g. IP) be passively opened?

Push

Push does local processing, then gives its packet to the lower session.

Pop and Demux

• Pop does local processing, then gives its packet to the next higher session.
• The question is, which is the next higher session?
• Answer: call the protocol's Demux to find out (see also picture on page 58)

Message Primitives

• Break
• Join
• Construct(Empty, Buffer, Allocate)

Very carefully designed to copy data as little as possible -- DAG of buffers.

Events

• Event evSchedule(EVFunc function, void * argument, int time)
• EvCancel
• evDetatch

• delta lists