basic networking & interprocess communication vivek pai nov 27, 2001

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