Basic Networking
Vivek Pai
Nov 26, 2002
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
2
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”
3
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
4
Measuring Latency
Here to Berkeley, CA
 Mapquest: 2898 miles (47 hours driving)
 Speed of light: 186000 miles/sec

– 15.6 ms (slightly slower than a disk access)

Ping: www.cs.berkeley.edu
– 84ms round trip (less than 3x slower)

Why? Packet switching
5
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
6
Mapping Packet Switching
% traceroute www.cs.berkeley.edu
traceroute to hyperion.cs.berkeley.edu (169.229.60.105), 64 hops max, 40 byte packets
1 ***
2 csgate.CS.Princeton.EDU (128.112.152.1) 5.847 ms 5.718 ms 5.652 ms
3 vgate1.Princeton.EDU (128.112.128.114) 5.400 ms 5.371 ms 5.306 ms
4 local.princeton.magpi.net (198.32.42.65) 6.873 ms 8.128 ms 6.597 ms
5 remote1.abilene.magpi.net (198.32.42.210) 9.515 ms 9.628 ms 10.071 ms
6 nycmng-washng.abilene.ucaid.edu (198.32.8.84) 14.259 ms 15.520 ms 14.007 ms
7 chinng-nycmng.abilene.ucaid.edu (198.32.8.82) 34.292 ms 34.326 ms 34.271 ms
8 iplsng-chinng.abilene.ucaid.edu (198.32.8.77) 50.394 ms 56.998 ms 46.205 ms
9 kscyng-iplsng.abilene.ucaid.edu (198.32.8.81) 47.535 ms 46.830 ms 61.605 ms
10 snvang-kscyng.abilene.ucaid.edu (198.32.8.102) 82.091 ms 82.941 ms 83.235 ms
11 snva-snvang.abilene.ucaid.edu (198.32.11.122) 82.910 ms 82.601 ms 81.987 ms
12 198.32.249.161 (198.32.249.161) 82.314 ms 82.394 ms 82.182 ms
13 BERK--SUNV.POS.calren2.net (198.32.249.13) 83.827 ms 84.060 ms 83.462 ms
14 pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89) 83.707 ms 83.579 ms 83.702 ms
15 vlan199.inr-202-doecev.Berkeley.EDU (128.32.0.203) 83.986 ms 148.940 ms 84.031 ms
16 doecev-soda-br-6-4.EECS.Berkeley.EDU (128.32.255.170) 84.365 ms 84.410 ms 84.167 ms
17 hyperion.CS.Berkeley.EDU (169.229.60.105) 84.506 ms 84.017 ms 84.393 ms
7
Abilene (Internet2) Nodes
8
Failure Behavior

What happens if
–
–
–
–

We send the packet
It reaches Sunnyvale
It meanders to Berkeley
Web server loses power
Can we avoid this situation?
9
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?
10
Do Applications Care?
Some do
 Most don’t

– Use whatever OS provides
– Good enough for most purposes

What do applications want?
– Performance
– Simplicity
11
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?
12
Kernel Internals
int
read(struct proc *p, struct read_args *uap)
{
register struct file *fp;
int error;
if ((fp = holdfp(p->p_fd, uap->fd, FREAD)) == NULL)
return (EBADF);
error = dofileread(p, fp, uap->fd, uap->buf,
uap->nbyte, (off_t)-1, 0);
fdrop(fp, p);
return(error);
}
13
Kernel Internals
int
dofileread(struct proc *p, struct file *fp, int fd, flags,
void *buf, size_t nbyte, off_t offset)
{
[…] (elided some code here)
cnt = nbyte;
if ((error = fo_read(fp, &auio, fp->f_cred, flags, p))) {
if (auio.uio_resid != cnt && (error == ERESTART ||
error == EINTR || error == EWOULDBLOCK))
error = 0;
}
cnt -= auio.uio_resid;
p->p_retval[0] = cnt;
return (error);
}
14
Kernel Internals
static __inline int
fo_read(struct file *fp, struct uio *uio,
struct ucred *cred, struct proc *p,
int flags)
{
int error;
fhold(fp);
error = (*fp->f_ops->fo_read)(fp, uio, cred,
flags, p);
fdrop(fp, p);
return (error);
}
15
Who Are These People
16
Gary Kildall


Founded Intergalactic Digital
Research
Wrote CP/M
–
–
–
–

Fairly portable
Wide use before IBM PC
Sales of $5.1M in 1981
Almost became PC’s OS
Died in 1994 from head
injuries
17
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( )
18
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( )
– Is a disk read different from a network read?
– When should a read return?
– What should a read return?
19
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);
20
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)
21
Sockets vs Shared Memory

Sockets
– Higher overhead
– No common parent/file needed
– “Active” operation – under program control

Shared memory
– Locking due to synchronous operation
– Fast reads/writes – no OS intervention
– Harder to use multiple machines
22