So headers get added as you go down the sender's layers (often
    called the PROTOCOL STACK or PROTOCOL SUITE).  They get used (and
    stripped off) as the msg goes up the receiver's stack.

    It all starts with process A sending a msg.  By the time it
    reaches the wire it has 6 headers (the physical layer doesn't add
    one--WHY?) and one trailer.

    Nice thing is that the layers are independent.  You can change one
    layer and not change the others.

HOMEWORK 10.1

    Now let's understand the layers themselves.

        Physical layer: hardware, i.e. voltages, speeds, duplexity,
        connectors

        Data link layer: Error correction and detection.  "Group the bits
        into units called frames". 

            Frames contain error detection (and correction) bits.

            This is what the pair of data like layers do when viewed
            as an extension of the physical.

            But when being used, the sending DL layer gets a packet
            from the network layer and breaks it into frames and adds
            the error detection bits.

        Network layer: Routing.

            Connection oriended network-layer protocol: X.25.  Send a
            msg to destination and establish a route that will be used
            for further msgs during this connection (a connection
            number is given).  Think telephone.

            Connectionless: IP (Internet Protocol).  Each PACKET
            (message between the network layers) is routed separately.
            Think post office.

        Transport layer: make reliable and ordered (but not always).

            Break incoming msg into packets and send to corresponding
            transport layer (really send to ...).  They are sequence
            numbered.

            Header contains info as to which packets have
            been sent and received.

            These sequence numbers are for the end to end msg.
            I.e. if allan.ultra.nyu.edu sends msg to allan.nj.nec.com
            the transport layer numbers the packets.  But these
            packets may take different routes.  On any one hop the
            data link layer keeps the frames ordered.

            If you use X.25 for network there is little for transport
            layer to do.

            If you use IP for network layer, there is a lot to do.

            Important transport layers are TCP (transmission control
            protocol) and UDP (Universal datagram protocol)

            TCP is connection oriented and reliable as described
            above.

            UDP is basically just IP (a "dummy") transport layer when
            you don't need that service (error rates are low already
            and msgs almost always come in order.

            TCP/IP is widely used.

        Session Layer: dialog and sync (we skip it)

        Presentation layer: Describes "meaning" of fields (we skip it).

        Application layer: For specific apps (e.g. mail, news, ftp)
        (we skip it)

Another (newer) famous protocol is ATM (asynchronous transfer mode)

    NOT in modern operating systems

    The hardware is better (newer) and has much higher data rates than
    previous long haul networks.

        155Mbits/sec compared to T3=45Mb/s is the low end.  622Mb/sec
        is midrange.

        In pure circuit switching a circuit is established and held
        (reserved) for the duration of the transmission.

        In store and forward packet switching, go one hop at at time
        with entire packet

        ATM estabilishes a circuit but it is not (exclusively)
        reserved.  Instead the packet is broken into smallish
        fixed-sized CELLS.  Cells from different transmissions can be
        interleaved on same wire

    Cute fact about high speed LONG haul network is that a LOT of bits
    are on the wires.  15ms from coast to coast.  So at 622Mb/sec,
    have 10Mb on the wire.  So if receiver says STOP, 20Mb will still
    come.  At 622Mb/set it takes 1.6ms to push a Mb file out of
    computer.  So if you wait for reply, most of the time the line is
    idle.

HOMEWORK Assume one interrupt to generate 8-bits and the interrupt
takes 1us to process.  Assume you are sending at a rate of 155Mb/sec.
What percent of the CPU time is being used to process the interrupts?      

Trouble in paradise

    The problem with all these layered things (esp OSI) is that all
    the layers add overhead.

    Especially noticable in systems with high speed interconnects
    where the processing time counts (i.e. not completely wire
    limited).

Clients and Servers

    Users and providers of services

    This provides more than communication.  It gives a structuring to
    the system.

    Much simplier protocol.

        Physical and datalink are as normal (hardware)

        All the rest is request/reply protocol

        Client sends a request; server sends a reply

        Less overhead than full OSI

    Minimal kernel support needed

        send (destination, message)

        receive (port, message)

        variants (mailboxes, etc) discussed later

Message format (example; triv file server)

    struct message
        source
        dest
        opcode
        count   -- number of bytes to read or write
        offset
        result
        filename                        
        data

Servers are normally infinite loops

    loop
        receive (port, message)
        switch message.opcode
            -- handle various cases filling in replymessage
        replymessage.result = result from case    
        send (message.source, replymessage)

Here is a client for copying A to B

    loop
        -- set (name=A, opcode=READ, count, position) in message
        send (fileserver, message)
        receive (port, replymessage) -- could use same message
        -- set (name=B, opcode=WRITE, count=result, position) in message
        send (fileserver, message)
        position +=result
    while result>0
    -- return OK or error code.

    Bug? If the read gets an error you send bogus (neg count) to write

    loop
        -- set (name=A, opcode=READ, count, position) in message
        send (fileserver, message)
        receive (port, replymessage) -- could use same message
    exit when result <=0
        -- set (name=B, opcode=WRITE, count=result, position) in message
        send (fileserver, message)
        position +=result
    end
    --return OK or error code

Addressing the server

    Need to specify the machine server is on and the "process" number

    Actually more common is to use the port number

        tanenbaum calls it local-id

        Server tells kernel that it wants to listen on this port

    Can we avoid giving the machine name (location transparency)?

        Can have each server pick a random number from a large space
        (so probability of duplicates is low).

        When a client wants service S it broadcasts a I need X and the
        server supplying X responds with its location.  So now the
        client knows the address.

        This first broadcast and reply can be used to eliminate
        duplicate servers (if desired) and different services
        accidentally using the same number

        Another method is to use a name server that has mapping from
        service names to locations (and local ids, i.e. ports).

            At startup servers tell the name server their location

            Name server a bottleneck?  Replicate and keep consistent

To block or not to block

    Synchronous vs asynchronous

    Send and receive synchronous is often called rendezvous

    Async send

        Do not wait for the msg to be recieved, return cntl immediately.

        How can you re-use the message variable

            Have the kernel copy the msg and then return.  This costs
            performance

            Don't copy but send interrupt when msg sent.  This makes
            programming harder

            Offer a syscall to tell when the msg has been sent.
            Similar to above but "easier" to program.  But difficult
            to guess how often to ask if msg sent