basic networking vivek pai nov 26, 2002. 2 communication you’ve already seen some of it –web...
Post on 21-Dec-2015
214 views
TRANSCRIPT
2
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
3
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”
4
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
5
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
6
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
7
Mapping Packet Switching
% traceroute www.cs.berkeley.edutraceroute 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 ms10 snvang-kscyng.abilene.ucaid.edu (198.32.8.102) 82.091 ms 82.941 ms 83.235 ms11 snva-snvang.abilene.ucaid.edu (198.32.11.122) 82.910 ms 82.601 ms 81.987 ms12 198.32.249.161 (198.32.249.161) 82.314 ms 82.394 ms 82.182 ms13 BERK--SUNV.POS.calren2.net (198.32.249.13) 83.827 ms 84.060 ms 83.462 ms14 pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89) 83.707 ms 83.579 ms 83.702 ms15 vlan199.inr-202-doecev.Berkeley.EDU (128.32.0.203) 83.986 ms 148.940 ms 84.031 ms16 doecev-soda-br-6-4.EECS.Berkeley.EDU (128.32.255.170) 84.365 ms 84.410 ms 84.167 ms17 hyperion.CS.Berkeley.EDU (169.229.60.105) 84.506 ms 84.017 ms 84.393 ms
9
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?
10
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?
11
Do Applications Care?
Some do Most don’t
– Use whatever OS provides– Good enough for most purposes
What do applications want?– Performance– Simplicity
12
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?
13
Kernel Internals
intread(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);}
14
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);
}
15
Kernel Internals
static __inline intfo_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);}
17
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
18
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( )
19
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?
20
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);
21
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)