1. Basic Networking Vivek Pai Nov 26, 2002

2. 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.11www.cs.princeton.edu

3. 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. 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. 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.eduwww.cs.berkeley.edu –84ms round trip (less than 3x slower)  Why? Packet switching

6. 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. 7 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

8. 8 Abilene (Internet2) Nodes

9. 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. 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. 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. 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. 13 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); }

14. 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. 15 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); }

16. 16 Who Are These People

17. 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. 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. 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. 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. 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)

22. 22 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