CPS 110 More Networks Landon Cox March 25

  • Slides: 58
Download presentation
CPS 110: More Networks Landon Cox March 25, 2008

CPS 110: More Networks Landon Cox March 25, 2008

Virtual/physical interfaces Applications OS Hardware

Virtual/physical interfaces Applications OS Hardware

Ordered messages ê Networks can re-order IP messages ê E. g. Send: A, B.

Ordered messages ê Networks can re-order IP messages ê E. g. Send: A, B. Arrive: B, A ê How should we fix this? ê Assign sequence numbers (0, 1, 2, 3, 4, …)

Ordered messages ê Do what for a message that arrives out of order? ê

Ordered messages ê Do what for a message that arrives out of order? ê (0, 1, 3, 2, 4) a. Save #3 and deliver after #2 is delivered ê (this is what TCP does) b. c. Drop #3, deliver #2, deliver #4 Deliver #3, drop #2, deliver #4 b. and c. are ordered, but not reliable (messages are dropped). Relies on the reliability layer to handle lost messages.

Ordered messages ê For a notion of order, first need “connections” ê Why? ê

Ordered messages ê For a notion of order, first need “connections” ê Why? ê Must know which messages are related to each other ê Idea in TCP ê Open a connection ê Send a sequence of messages ê Close the connection ê Opening a connection ties two sockets together ê Connection is socket-to-socket unique: only these sockets can use it ê Sequence numbers are connection specific

Virtual/physical interfaces Applications OS Hardware

Virtual/physical interfaces Applications OS Hardware

Reliable messages ê Usually paired with ordering ê TCP provides both ordering and reliability

Reliable messages ê Usually paired with ordering ê TCP provides both ordering and reliability ê Hardware interface ê Network drops messages ê Network duplicates messages ê Network corrupts messages ê Application interface ê Every message is delivered exactly once

Detecting and fixing drops ê How to fix a dropped message? ê Have sender

Detecting and fixing drops ê How to fix a dropped message? ê Have sender re-send it ê How does sender know it’s been dropped? ê Have receiver tell the sender ê Receiver may not know it’s been sent ê Like asking in the car, ê “If we left you at theater, speak up. ”

Detecting and fixing drops ê Have receiver acknowledge each message ê Called an “ACK”

Detecting and fixing drops ê Have receiver acknowledge each message ê Called an “ACK” ê If sender doesn’t get an ACK ê Assume message has been dropped ê Resend original message ê Is this ok for the sender to assume? ê No. ACKs can be dropped too (or delayed)

Detecting and fixing drops ê Possible outcomes ê Message is delayed or dropped ê

Detecting and fixing drops ê Possible outcomes ê Message is delayed or dropped ê ACK is delayed or dropped ê Strategy ê Deal with all as though message was dropped ê Worst case if message wasn’t dropped after all? ê Need to deal with duplicate messages ê How to detect and fix duplicate messages? ê Easy. Just use the sequence number and drop duplicate.

What about corruption? ê Messages can also be corrupted ê Bits get flipped, etc

What about corruption? ê Messages can also be corrupted ê Bits get flipped, etc ê Especially true over wireless networks ê How to deal with this? ê Add a checksum (a little redundancy) ê Checksum usually = sum of all bits ê Drop corrupted messages

What about corruption? ê Dropping corrupted messages is elegant ê Transforms problem into a

What about corruption? ê Dropping corrupted messages is elegant ê Transforms problem into a dropped message ê We already know how to deal with drops ê Common technique ê Solve one problem by transforming it into another 1. Corruption drops 2. Drops duplicates 3. Drop any duplicate messages (very simple)

Virtual/physical interfaces Applications OS Hardware

Virtual/physical interfaces Applications OS Hardware

Byte streams ê Hardware interface ê Send information in discrete messages ê Application interface

Byte streams ê Hardware interface ê Send information in discrete messages ê Application interface ê Send data in a continuous stream ê Like reading/writing from/to a file

Byte streams ê Many apps think about info in distinct messages ê What if

Byte streams ê Many apps think about info in distinct messages ê What if you want to send more data than fits? ê UDP max message size is 64 KB ê What if data never ends? ê Streamed media ê TCP provides “byte streams” instead of messages

Byte streams ê Sender writes messages of arbitrary size ê TCP breaks up the

Byte streams ê Sender writes messages of arbitrary size ê TCP breaks up the stream into fragments ê Reassembles the fragments at destination ê Receiver sees a byte stream ê Fragments are not visible to either process ê Programming the receiver ê Must loop until certain number of bytes arrive ê Otherwise, might get first fragment and return

Byte streams ê UDP makes boundaries visible ê TCP makes boundaries invisible ê (loop

Byte streams ê UDP makes boundaries visible ê TCP makes boundaries invisible ê (loop until you get everything you need) ê How to know # of bytes to receive? 1. Size is contained in header 2. Read until you see a pattern (sentinel) 3. Sender closes connection

Sentinels ê Idea: message is done when special pattern arrives ê Example: C strings

Sentinels ê Idea: message is done when special pattern arrives ê Example: C strings ê How do we know the end of a C string? ê When you reach the null-termination character (‘’) ê Ok, now say we are sending an arbitrary file ê Can we use ‘’ as a sentinel? ê No. The data payload may contain ‘’ chars ê What can we do then?

Course administration ê Project 2 is due today ê Scores: 84, 81, 75, 73,

Course administration ê Project 2 is due today ê Scores: 84, 81, 75, 73, 57, 54, 53, 48, 47, 40, 27, 5 ê Project 3 will be out next week ê Socket programming how-to posted ê Amre will cover in discussion section this week ê Will post example client/server code ê Any questions?

Distributed systems You use distributed systems everyday. Both on your PC and behind the

Distributed systems You use distributed systems everyday. Both on your PC and behind the scenes.

Motivation for distributed apps 1. Performance

Motivation for distributed apps 1. Performance

Motivation for distributed apps 1. Performance 2. Co-location 4 Can locate computer near local

Motivation for distributed apps 1. Performance 2. Co-location 4 Can locate computer near local resources 4 Examples of local resources 4 People, sensors, sensitive database

Motivation for distributed apps 1. Performance 2. Co-location 3. Reliability 4 Not all computers

Motivation for distributed apps 1. Performance 2. Co-location 3. Reliability 4 Not all computers will go down at once 4 Due to floods, fires, earthquakes, etc 4 Better chance of continuous service

Motivation for distributed apps 1. 2. 3. 4. Performance Co-location Reliability Already have multiple

Motivation for distributed apps 1. 2. 3. 4. Performance Co-location Reliability Already have multiple machines 4 Can’t put everyone on one machine 4 Try to stitch existing machines together

Building up to distributed apps ê Needed two things in multi-threaded programs 1. Atomic

Building up to distributed apps ê Needed two things in multi-threaded programs 1. Atomic primitives to control thread interleavings ê (interrupt disable/enable, atomic test&set) 2. Way to share information between threads ê (shared address space) ê These won’t work for distributed applications ê No interrupt disable/enable or atomic test&set ê No shared memory

Building up to distributed apps ê Can only communicate through messages ê Send messages

Building up to distributed apps ê Can only communicate through messages ê Send messages ê Receive messages ê If no shared data, are there race conditions? ê Sure, races expose shared data in inconsistent state ê Races can cause other problems too ê Incorrect event ordering (fire missile after command) ê Mutual exclusion (two people stocking same fridge)

Send/receive primitives ê So we need sharing and synchronization 1. Obvious we can use

Send/receive primitives ê So we need sharing and synchronization 1. Obvious we can use send/receive to share ê Each message communicates information ê Messages instead of load/store to shared memory 2. Can we use send/receive for synchronization? ê Depends on the atomicity of our hardware primitives ê “Try to build large atomic regions from small ones. ”

Send/receive primitives ê Atomic operation provided by hardware ê Can send a single Ethernet

Send/receive primitives ê Atomic operation provided by hardware ê Can send a single Ethernet frame atomically ê Ethernet detects simultaneous sends ê Called a collision ê Ethernet either allows one or none ê A bigger problem in wireless networks ê Idea: build up from atomic send X

Send/receive primitives ê Interleaved incoming packets ê OS separates the packets ê Forms whole

Send/receive primitives ê Interleaved incoming packets ê OS separates the packets ê Forms whole messages from fragments ê Passes messages up to various apps ê How does OS know which packet goes to which app? ê Port number in L 4 (TCP, UDP, etc) header

Send/receive primitives ê Interleaved outgoing packets ê OS ensures packets are whole ê One

Send/receive primitives ê Interleaved outgoing packets ê OS ensures packets are whole ê One app’s packets won’t change another’s ê How does OS control access to the NIC? ê Device driver “serializes” send requests ê Use locks inside driver code

Client-server ê Many different distributed architectures ê Client-server is the most common ê Also

Client-server ê Many different distributed architectures ê Client-server is the most common ê Also called request-response “GET /images/fish. gif HTTP/1. 1” ê Basic interaction

Client-server ê Clients are machines you sit in front of ê Send request to

Client-server ê Clients are machines you sit in front of ê Send request to server ê Wait for a response ê Clients generally initiate communication ê Writes are similar POST /cgi-bin/uploadfile. pl HTTP/1. 1 Content-Type: application/x-www-form-urlencoded Content -Length: 49 filename=foo. txt&file+content=content+of+foo. txt

Producer-consumer Delivery person (producer) Soda drinker (consumer) Vending machine (buffer)

Producer-consumer Delivery person (producer) Soda drinker (consumer) Vending machine (buffer)

Producer-consumer ê Have a server manage the coke machine ê Clients can call two

Producer-consumer ê Have a server manage the coke machine ê Clients can call two functions ê client_produce () ê client_consume () ê Both send a request to the server ê Both return when the request is done

Producer-consumer client_produce () { send message to add coke wait for response } client_consume

Producer-consumer client_produce () { send message to add coke wait for response } client_consume () { send message to get coke wait for response } server () { receive request (from any producer or consumer client) if (request is from a producer) { wait for empty spot in machine put coke in machine } else { wait for coke in machine take coke out of machine Anything missing? } Need to wait for cokes/space. send response }

Producer-consumer client_produce () { send message to add coke wait for response } client_consume

Producer-consumer client_produce () { send message to add coke wait for response } client_consume () { send message to get coke wait for response } server () { receive request (from any producer or consumer client) if (request is from a producer) { wait for empty spot in machine put coke in machine } else { wait for coke in machine Does this work? take coke out of machine } No. Now we’ll deadlock. send response }

Producer-consumer client_produce () { send message to add coke wait for response } client_consume

Producer-consumer client_produce () { send message to add coke wait for response } client_consume () { send message to get coke wait for response } server () { receive request (from any producer or consumer client) if (request is from a producer) { wait for empty spot in machine put coke in machine } else { wait for coke in machine How do we solve this? take coke out of machine } Use threads at the server. send response }

Producer-consumer server () { while (1) { receive request (from any producer or consumer

Producer-consumer server () { while (1) { receive request (from any producer or consumer client) if (request is from a producer) { create a thread to handle the produce reqeust } else { create a thread to handle the consumer request } } } server_consume () { server_produce () { lock while (machine is empty) while (machine is full) wait take coke from machine put coke in machine send response to client unlock } }

Producer-consumer ê Note how we used send/receive ê Used to share information ê (request/response

Producer-consumer ê Note how we used send/receive ê Used to share information ê (request/response messages) ê Provides before/after constraint ê (client waits for server) ê Receive is like wait/down, send is like signal/up ê Solution creates a thread per request ê Can we lower the per-request overhead?

Producer-consumer ê Keep a pool of worker threads ê When main loop gets a

Producer-consumer ê Keep a pool of worker threads ê When main loop gets a request ê Pass request to an existing worker thread ê When worker thread is done ê Wait for next request from dispatcher ê Similar to disk scheduler in P 1

Other approaches ê Don’t have to use worker threads ê Just want slow operations

Other approaches ê Don’t have to use worker threads ê Just want slow operations to run in parallel ê What are the slow operations? ê Producing/consuming a coke ê Receiving a network request

Other approaches ê Want server to work while waiting for requests ê Could poll

Other approaches ê Want server to work while waiting for requests ê Could poll (using the select() system call) ê Instead of blocking in recv() ê Poll to see if there is a new message, call recv() if there is ê Also must avoid calling wait() if there is no coke/space ê Could use signals (SIGIO) ê Incoming network messages generate a signal ê The signal interrupts the thread blocked in wait() ê Threads are a much easier solution!

Network abstractions ê We’ve been using send/receive ê Client sends a request to the

Network abstractions ê We’ve been using send/receive ê Client sends a request to the server ê Server receives request ê Server sends response to client ê What else in CS is this interaction like? ê Calling a function

Remote procedure call (RPC) ê RPC makes request/response look local ê Provide a function

Remote procedure call (RPC) ê RPC makes request/response look local ê Provide a function call abstraction ê RPC isn’t a really a function call ê In a normal call, the PC jumps to the function ê Function then jumps back to caller ê This is similar to request/response though ê Stream of control goes from client to server ê And then returns back to the client

The RPC illusion ê How to make send/recv look like a function call? ê

The RPC illusion ê How to make send/recv look like a function call? ê Client wants ê Send to server to look like calling a function ê Reply from server to look like function returning ê Server wants ê Receive from client to look like a function being called ê Wants to send response like returning from function

RPC stub functions ê Key to making RPC work ê Stub functions

RPC stub functions ê Key to making RPC work ê Stub functions

RPC stub functions call return call Client stub Server stub send recv

RPC stub functions call return call Client stub Server stub send recv

RPC stub functions ê Client stub 1) Builds request message with server function name

RPC stub functions ê Client stub 1) Builds request message with server function name and parameters 2) Sends request message to server stub ê (transfer control to server stub) 8) Receives response message from server stub 9) Returns response value to client ê Server stub 3) Receives request message 4) Calls the right server function with the specified parameters 5) Waits for the server function to return 6) Builds a response message with the return value 7) Sends response message to client stub

RPC notes ê Client makes a normal function call ê Can’t tell that it’s

RPC notes ê Client makes a normal function call ê Can’t tell that it’s to a remote server (sort of) ê Server function is called like a normal function ê Can’t tell that it’s returning to a remote client ê Control returns to client as if from a function call ê Common technique to add functionality ê Leaving existing component interfaces in-place ê Implement both sides between existing layers ê CORBA, COM, SOAP are implemented this way

RPC example ê Client calls produce(5) Client stub: Server stub: // must be named

RPC example ê Client calls produce(5) Client stub: Server stub: // must be named produce! int produce (int n) { int status; send (sock, &n, sizeof(n)); recv (sock, &status, sizeof(status)); return status; } // could be named anything void produce_stub () { int n; int status; recv (sock, &n, sizeof(n)); // produce func on server! status = produce (n); send (sock, &status, sizeof(status)); } Server stub code can be generated automatically (C/C++: rpcgen, Java: rmic) What info do you need to generate the stubs? Input parameter types and the return value type.

Java RMI example ê Remote calculator program

Java RMI example ê Remote calculator program

Problems with RPC ê How is RPC different from local function calls? ê Hard

Problems with RPC ê How is RPC different from local function calls? ê Hard to pass pointers (and global variables) ê What happens if server dereferences a passed-in pointer? ê Pointer will access server’s memory (not client’s) ê How do we solve this? ê Send all data reachable from pointer to the server ê Change the pointers on the server to point to the copy ê Copy data back when server function returns

Example RPC with pointers ê On client: int a[100]; ê Want to send “a”

Example RPC with pointers ê On client: int a[100]; ê Want to send “a” (a pointer to an array) ê Copy entire array to server ê Have server’s pointer point to copy of a ê Copy array back to client on return ê What if a is more complicated? A linked list? ê Have to marshal the transitive closure of pointer

Problems with RPC ê Data may be represented differently ê Machines have different “endianness”

Problems with RPC ê Data may be represented differently ê Machines have different “endianness” ê Byte 0 may be least or most significant ê Must agree on standard network representation ê RPC has different failure modes ê Server or client can fail during a call ê In local case, client and server fail simultaneously

Finishing RPC ê Where have you used RPC in CPS 110? ê Project 2

Finishing RPC ê Where have you used RPC in CPS 110? ê Project 2 infrastructure ê C library interface to system calls is similar ê Makes something look like a function call

Structuring a concurrent system ê Talked about two ways to build a system

Structuring a concurrent system ê Talked about two ways to build a system

Alternative structure ê Can also give cooperating threads an address space ê Each thread

Alternative structure ê Can also give cooperating threads an address space ê Each thread is basically a separate process ê Use messages instead of shared data to communicate ê Why would you want to do this? ê Protection ê Each module runs in its own address space ê Reasoning behind micro-kernels ê Each service runs as a separate process ê Mach from CMU (influenced parts Mac OS X) ê Vista’s handling of device drivers

Rest of the semester ê On Tuesday we’ll begin security ê Project 3 will

Rest of the semester ê On Tuesday we’ll begin security ê Project 3 will be a new security project ê After security, we’ll cover file systems ê Probably a guest lecture along the way ê Finish up with Google