Basic Networking Vivek Pai Nov 26, 2002
Download
Report
Transcript Basic Networking Vivek Pai Nov 26, 2002
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