Basic Networking

1. Basic Networking Vivek Pai Nov 26, 2002

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.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. Abilene (Internet2) Nodes

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 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. 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 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. Who Are These People

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)

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