CS 326: Operating Systems Networking Lecture 17
Today s Schedule Project 3 Overview, Q&A Networking Basics Messaging 4/23/18 CS 326: Operating Systems 2
Today s Schedule Project 3 Overview, Q&A Networking Basics Messaging 4/23/18 CS 326: Operating Systems 3
Project Overview 4/23/18 CS 326: Operating Systems 4
Today s Schedule Project 3 Overview, Q&A Networking Basics Messaging 4/23/18 CS 326: Operating Systems 5
Network Terminology Host computer/device connected to a network. Communicate via packets Packet a unit of data, generally represented as a sequence of bytes Router device that forwards packets through the network until they reach their destination host A message may pass through several routers on its way to the destination Protocol defines how packets are laid out 4/23/18 CS 326: Operating Systems 6
TCP We use the Internet Protocol (IP) Suite for a majority of our communications For reliable delivery, we use the Transmission Control Protocol (TCP) Modeled as a stream of bytes Packets will reach their destination (eventually ) and the contents are verified Retransmit when a failure/corruption occurs Packets are received in order 4/23/18 CS 326: Operating Systems 7
UDP User Datagram Protocol (UDP) on the other hand, is connectionless Rather than a stream of bytes, we deal with discrete messages No acknowledgment or retransmission Ordering is not guaranteed Used for games, video streaming, and other applications where delivery needn t be guaranteed 4/23/18 CS 326: Operating Systems 8
TCP or UDP In Project 3, we will be using TCP for communication No need to worry about messages getting delivered Won t have to reconstruct out-of-order files getting transferred between our client/server 4/23/18 CS 326: Operating Systems 9
Sockets The standard API for network communication is sockets Introduced in 1983, 4.2 BSD UNIX Sockets follow the Unix philosophy: everything is a file! When we open a connection, we get a file descriptor that we can read() and write() from Just like a file or pipe 4/23/18 CS 326: Operating Systems 10
Virtualizing the Network Since this is OS class, we need to discuss how to virtualize the network to allow multiple processes to communicate at the same time We accomplish this via ports Each outgoing and incoming socket connection is assigned a port number 16-bit unsigned integer (max: 65535) 4/23/18 CS 326: Operating Systems 11
Ports Want to talk to the web server process? Connect to port 80 How about SSH? Port 22! Processes bind to these ports and listen on them When initiating an outgoing connection (e.g., from your browser) you can assign any available port 4/23/18 CS 326: Operating Systems 12
Privileged Ports The first 1024 ports are privileged Must be root to bind to these ports The standard SSH port is 22, but what if a user application could bind to port 22 before the SSH daemon starts up? You could masquerade as SSH and steal passwords! And yes: you can bind to any port you want. SSH could run on port 80 (commonly www) if you want! 4/23/18 CS 326: Operating Systems 13
Basic Server Workflow Create a socket: socket() Bind to a port: bind() Listen for connections: listen() Accept incoming connections: accept() Returns a file descriptor Write/read data to/from the FD: write() / read() TCP is bidirectional: you can send and receive from the same FD 4/23/18 CS 326: Operating Systems 14
Basic Client Workflow Create a socket: socket() Connect to the remote host: connect() Specify remote IP address and port number Write/read data to/from the FD: write() / read() TCP is bidirectional: you can send and receive from the same FD Usually the client starts off with a write() but it doesn t necessarily have to work this way 4/23/18 CS 326: Operating Systems 15
Some Issues (1/2) The first unintuitive thing about sockets is there is no concept of a message You can t send a struct over the wire and then receive it on the other end At least not directly! Instead, everything gets read/written as byte arrays (streams of bytes) Not all the bytes will come in at the same time, although order is guaranteed with TCP 4/23/18 CS 326: Operating Systems 16
Some Issues (2/2) A read() or write() call may not actually read/write the number of bytes you ask for You have to check! Maybe only 10 bytes have been received and we want 100 read() can still return with those initial 10 bytes We have to store incoming data in a buffer and update it as necessary! 4/23/18 CS 326: Operating Systems 17
Network Concerns At the OS level, we can mostly rely on the network to do its job But we still have to make decisions about how to implement networking logic For instance, TCP vs UDP And we need to think about: Bandwidth Latency 4/23/18 CS 326: Operating Systems 18
Bandwidth Also known as throughput How many bits we can push through the network Trending upward over time slowly 1000 Mbps networks are common in data centers 10 Gbps is gaining some traction Many home internet services are still in the range of 25-100 Mbps If we re going to use plumbing metaphors, it s the size of the pipe 4/23/18 CS 326: Operating Systems 19
Latency How long it takes your bits to get from one point to another Latency has been trending downward overall, but not by leaps and bounds We are limited by the laws of physics here How long the pipe is and how fast data can travel through it Some communication mediums are more prone to latency: Ethernet vs WiFi 4/23/18 CS 326: Operating Systems 20
Round Trip Times Another factor to consider is the round-trip time RTTs Another way of looking at latency Communication rarely goes one way Even if you re uploading a file, you d like to confirm that it actually made it over in one piece Testing RTTs: pinging a host 4/23/18 CS 326: Operating Systems 21
Ping Round Trip Times PING alpha.lan (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.133 ms (From my couch to the closet) PING stargate.cs.usfca.edu (138.202.168.21): 56 data bytes 64 bytes from 138.202.168.21: icmp_seq=0 ttl=53 time=15.640 ms (Down the road to USF) PING ruby.cs.colostate.edu (129.82.45.204): 56 data bytes 64 bytes from 129.82.45.204: icmp_seq=0 ttl=50 time=70.991 ms (Fort Collins, Colorado) PING speedtest.shg1.linode.com (139.162.65.37): 56 data bytes 64 bytes from 139.162.65.37: icmp_seq=0 ttl=50 time=124.017 ms (Singapore) 4/23/18 CS 326: Operating Systems 22
Interesting: Physical Distances From my laptop to my router: 15 feet / 4.60 m From my router to USF: 2 miles / 3.2 km From USF to Colorado: ~950 miles / 1609 km From USF to Singapore: ~8,434 miles / 13,573 km https://www.submarinecablemap.com 4/23/18 CS 326: Operating Systems 23
Source: https://www.submarinecablemap.com 4/23/18 CS 326: Operating Systems 24
Source: https://www.submarinecablemap.com 4/23/18 CS 326: Operating Systems 25
Bandwidth-Delay Product (1/2) Link capacity (bps) * Round-trip delay time (s) This measures how many bits are in flight How much data is sent before the receiver gets anything A network with a large bandwidth-delay product is called a long fat network, or LFN (elephen) Satellite networking has a large bandwidth-delay product 4/23/18 CS 326: Operating Systems 26
Bandwidth-Delay Product (2/2) Important because of its interplay with TCP TCP dynamically tunes its window size If the window is too small, link capacity is wasted If the window is too large, the other end gets overwhelmed! Queuing delays Thinking back to our ping example: My local network (300 Mbit/sec, 1.1 ms) = 0.14 MB Singapore (50 Mbit/sec, 124.0 ms) = 0.78 MB 4/23/18 CS 326: Operating Systems 27
Today s Schedule Project 3 Overview, Q&A Networking Basics Messaging 4/23/18 CS 326: Operating Systems 28
Simple Messaging (1/3) If you want to send one well-defined message between components, all you need is a fixed-size buffer: char buffer[25]; Remember: sockets are byte streams, not message streams A much more common format: 4/23/18 CS 326: Operating Systems 29
Simple Messaging (2/3) Once you ve unpacked the message payload, it can contain more fields: This allows for a layered approach: Network code Message creation code Pass through a chain of handlers 4/23/18 CS 326: Operating Systems 30
Simple Messaging (3/3) If you don t need advanced features, size prefixed messages work well Exceptions: You d like to avoid reading the entire message before you start processing it You don t even need to process the whole message (perhaps you are forwarding it somewhere else) Network wire formats have a huge range of features and complexity 4/23/18 CS 326: Operating Systems 31
Serialization Serialization transforms an object, structure, or application state into a format for transmission (and often storage to disk) Most common: binary formats Better performance When you receive a serialized message, transforming it back into its original representation is called deserialization 4/23/18 CS 326: Operating Systems 32
Our Message Format I d recommend you include length and type fields at the start of your messages You can use structs to make this easier However, they should be packed Read in the length, which tells you how many more bytes to read before the message is complete Use a switch/if-else block on the type: If (type == 4) { /* handle message type 4 */ } Else if (type == 5) { /* handle message type 5 */ } 4/23/18 CS 326: Operating Systems 33
Struct Packing If we have a struct with two integers and a 24- character char array, then we can make some guesses as to how it looks in memory However, there is no guarantee of order or size The C compiler may decide to pad the struct for performance reasons We can pack our structs to ensure what we see is what we get. We ll use this in HW6 4/23/18 CS 326: Operating Systems 34