Basic Networking & Interprocess Communication Vivek Pai Nov 27, 2001
Dec 22, 2015
Basic Networking & Interprocess Communication
Vivek Pai
Nov 27, 2001
2
Everyone’s Getting Sick
Including me– Didn’t assign reading in syllabus– Did get rough grades computed– Still have one feedback missing– Putting off new project this week
3
Mechanics
Next project assigned next Tuesday Only 5 projects instead of 6 Target: use threads, synchronization
– Probably using webserver again– Not building on filesystem– Suggestions welcome
We’ve completely neglected the dining philosophers problem!
4
Dining Philosophers
5
Possible Solutions
Philosophers go in order Place numbers on forks If stuck, drop fork, try again Defer by age or some other quantity Stab each other
6
Deadlock “Solutions”
Eliminate parallelism Order resources, grab in order Determine priorities on contention Restart & randomize
Deadlock performance: cost of avoiding/detecting deadlock versus work frequency & work thrown away
7
Original Lecture Goals
Basic networking - Introduce the basics of networking, the new semantics versus standard file system calls, and how this affects the programming model. Discuss network basics such as naming, ports, connections, protocols, etc.
Interprocess communication - Show how “networking” is useful within a single machine to communicate data. Give examples of different domains, how they are implemented, and the effects within the kernel. Show how networking and interprocess communication can be used to allow easy distribution of applications.
8
Communication
You’ve already seen some of it– Web server project(s)
Machines have “names”– Human-readable names are convenience– “Actual” name is IP (Internet Protocol) address– For example, 127.0.0.1 means “this machine”– nslookup www.cs.princeton.edu gives
128.112.136.11
9
Names & Services
Multiple protocols– ssh, ftp, telnet, http, etc.– How do we know how to connect?
Machines also have port numbers– 16 bit quantity (0-65535)– Protocols have default port #– Can still do “telnet 128.112.136.11 80”
10
But The Web Is Massive
Possible names >> possible IP addresses– World population > possible IP addresses
– Many names map to same IP addr
– Use extra information to disambiguate
– In HTTP, request contains “Host: name” header Many connections to same (machine, port #)
– Use (src addr, src port, dst addr, dst port) to identify connection
11
Circuit Switching versus Packet Switching
Circuit – reserve resources in advance– Hold resources for entire communication– Example: phone line
Packet – break data into small pieces– Pieces identify themselves, “share” links– Individual pieces routed to destination– Example: internet– Problem: no guarantee pieces reach
12
Who Got Rich By Packet Switching?
13
The “End To End” Argument
Don’t rely on lower layers of the system to ensure something happens
If it needs to occur, build the logic into the endpoints
Implications:– Intermediate components simplified– Repetition possible at endpoints (use OS)
What is reliability?
14
Do Applications Care?
Some do Most don’t
– Use whatever OS provides– Good enough for most purposes
What do applications want?– Performance– Simplicity
15
Reading & Writing
A file:– Is made into a “descriptor” via some call– Is an unstructured stream of bytes– Can be read/written– OS provides low-level interaction– Applications use read/write calls
Sounds workable?
16
Network Connections As FDs
Network connection usually called “socket” Interesting new system calls
– socket( ) – creates an fd for networking use– connect( ) – connects to the specified machine– bind( ) – specifies port # for this socket– listen( ) – waits for incoming connections– accept( ) – gets connection from other machine
And, of course, read( ) and write( )
17
New Semantics
Doing a write( )– What’s the latency/bandwidth of a disk?– When does a write( ) “complete”?– Where did data actually go before?– Can we do something similar now?
What about read( )– When should a read return?– What should a read return?
18
Buffering
Provided by OS– Memory on both sender and receiver sides– Sender: enables reliability, quick writes– Receiver: allows incoming data before read
Example – assume slow network– write(fd, buf, size);– memset(buf, 0, size)– write(fd, buf, size);
19
Interprocess Communications
Shared memory– Threads sharing address space– Processes memory-mapping the same file– Processes using shared memory system calls
Sockets and read/write– Nothing prohibits connection to same machine– Even faster mechanism – different “domain”– Unix domain (local) versus Internet (either)
20
Sockets vs Shared Memory
Sockets– Higher overhead– No common parent/file needed– Synchronous operation
Shared memory– Locking due to synchronous operation– Fast reads/writes – no OS intervention– Harder to use multiple machines
21
Even More Semantics
How do you express the following:– Do (task) until (message received)– Do (this task) until (receiver not ready)– Do (task) until (no more data)
Problem: implies knowing system behavior Related: what happens when buffer
fills/empties? (hint: think of filesystem)
22
Synchronous vs Asynchronous
Synchronous: do it now, wait until over Asynchronous: start it now, check later
Somewhat related: Blocking: wait until it’s all done Nonblocking: only do what can be done
without blocking
23
Transferring Large Files
OS buffers are 16-64KB Large files are >> buffer size Assume two clients
– Each requests a different large file– Both are on slow networks
How do you design your server?
24
Server Design Choices
Processes– Each client handled by a different process
Threads– Each client handled by a different thread
Single process– Use nonblocking operations, multiplex
25
Processing Steps
Read File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Headerend
26
Blocking Steps
Read File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Headerend
Network Blocking
Disk Blocking
27
Concurrency Architecture
Overlap disk, network, & application-level processing
Architecture how steps are overlapped
Note: implications for performance
28
Multiple Processes (MP)
Pro: simple programming – rely on OSCons: too many processes
caching harder
Process 1Read File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Header
Process NRead File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Header
29
Multiple Threads (MT)
Pro: shared address spacelower “context switch” overhead
Cons: many threadsrequires kernel thread supportsynchronization needed
Read File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Header
30
Single Process Event Driven (SPED)
Pro: single address spaceno synchronization
Cons: must explicitly handle piecesin practice, disk reads still block
Read File
Send Data
Accept
Conn
Read
Request
Find
File
Send
Header
Event Dispatcher
31
Homework
Read about the select( ) system call Reading from syllabus I may send an e-mail with papers