New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

CSE 489 Week 3 Notes

by: Winnie Liang

CSE 489 Week 3 Notes CSE 489

Winnie Liang

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Week 3
Modern Networking Concepts
Dimitrios Koutsonikolas
Class Notes
CSE 489 Week 3 Notes Modern Networking Concepts University at Buffalo
25 ?




Popular in Modern Networking Concepts

Popular in Computer Science and Engineering

This 33 page Class Notes was uploaded by Winnie Liang on Sunday February 14, 2016. The Class Notes belongs to CSE 489 at University at Buffalo taught by Dimitrios Koutsonikolas in Spring 2016. Since its upload, it has received 21 views. For similar materials see Modern Networking Concepts in Computer Science and Engineering at University at Buffalo.


Reviews for CSE 489 Week 3 Notes


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 02/14/16
CSE 489 Week 3 02/14/2016 ▯ Recitation 2/8/16 ▯ Programming Assignment 1 ▯ How to run your program: ▯ - Server: $ ./assignment1 s 4322 ▯ - Client: $ ./assignment1 c 4322 ▯ **port number is defined as 4322. Clients contact servers not the other way around therefore we need port number ▯ - Shell: [PA1] $ IP ▯ [PA1] $ LOGIN 4322 (ip of server) (port number of server) ▯ All commands in UPPER CASE “IP” “LOGIN” “HELP” ▯ How to recognize command input? ▯ – tokenize input – use string tokenizer using a space “ “ character ▯ (LOGIN | | 4322) ▯ ex. ▯ argc =0; ▯ arg = strtok(cmd, “ “); ▯ while(arg){ ▯ strcpy(argv[argc], ar); ▯ argc += 1; //keeps count of arguments ▯ arg = strtok(NULL, “ ”); //calls next argument ▯ } ▯ ▯ - compare with first index to the commands ▯ if( !(strcmp(argv[0], “HELP”)) ){ ▯ ▯ Commands expected: - [PA1]$ IP ---- expected output: ▯ IP: ▯ - Display external/public IP address ▯ - is NOT the correct address ▯ - Create a UDP socket to any valid destination IP address – call connect to that UDP socket (IP address is valid if it’s in this format: each is up from 0-55 ▯ - [PA1]$ PORT ----- expected output: ▯ PORT:4322 ▯ Display the port number ▯ - [PA1]$ LOGIN 4322 ▯ - Clients login to the server  Identify themselves to server  Get list of other logged-in clients (ex. Client 1, Client 2, Client 3)  Get buffered messages (when they’re logged out, then they log in, they still receive their messages)  Refresh command  Exit command on one of these clients ▯ - [PA1]$ LIST ▯ - List the currently logged-in clients (if client 3 is loggedin, we get a list of client 1 and 2) ▯ for (host=0; host<MAX_HOSTS; host+=1){ ▯ ▯ printf(….. host_id, host_name, ip_addr, --------) ▯ - [PA1]$ SEND Hello ▯ - Send message to client with IP address: ▯, through the SERVER ▯ - Max length of message: 256 bytes ▯ - Only valid ASCII characters ▯ - [PA1]$ LOGOUT ▯ - Logout from the server ▯ - Do not terminate/exit the application; user should be able to still type in commands ▯ - Server should buffer messages for logged-out clients ▯ - [PA1]$ EXIT ▯ - LOGOUT and exit the application with status code 0 ▯ - No buffering messages for clients ▯ ▯ TCP Socket Flow ▯ TCP Server Commands – socket() -> bind() -> listen() -> accept() -> ▯ read() -> write() -> read() -> close() ▯ ▯ bind tells server what to do with socket ▯ listen tells server how many connections from underneathe layers ▯ accept() is blocked until some data arrives at socket ▯ ▯ TCP Client Commands- ▯ socket() -> connect() -> write() -> read() -> close() ▯ ▯ Server Socket Setup ▯ **LOOK AT CODE IN THE RECITATION SLIDES* ▯ ▯ IPv4 – AF_INET_4 ▯ IPv6 – AF_INET_6 ▯ DATAGRAM protocols (end up with one LDP) ▯ SOCK_STREAM protocols (end up with 1 TCP) ▯ ▯ SOCK_DGRAM ▯ 0 ▯ ▯ server_socket = socket(AF_INET, SOCK_STREAM, 0); ▯ ▯ socket that you want to use – AF_INET ▯ IP Address you want to listen on – INADDR_ANY ▯ Port you want to listen on – port ex. 4322 ▯ ▯ bind() wants to listen at this port number , if < 0 , “bind failed” ▯ listen() – how many open connections it should allow, if < 0, “unable to listen to port” ▯ ▯ accept() – it WAITS for an accepting connection ▯ (***LOOK AT RECITATION SLIDE***) ▯ size of int is passed as reference & - client address ▯ ▯ Now to…..Client side – connect() ▯ server_ip (HEXADECIMAL ip in an array) and port number is of the SERVER’s ▯ accept() is another socket – generates a new socket.. is free to accept new connections – this socket is used to talk to clients ▯ ▯ Select based I/O ▯ - select()  For I/O Multiplexing o Command input on shell, TCP port listening, data incoming .. o File descriptors (integer)  System initialized OR User created/defines (eg. Files, socket())  Integer Values – 0: Standard input (stdin), 1: Standard output (stdout), 2: Standard Error (stderror) ▯ - select() API function calls  Add fd (file descriptor) to the set o FD_SET(int fd, fd_set *set); o FD_CLR o FD_ISSET o FD_ZERO ▯ Select() listens to file descriptors for sockets ▯ - we create a set of file_descriptors ▯ we need two lists – everytime you call select, you have to initialize &master_list and pass it on to &watch_list ▯ ▯ head_socket = highest socket + 1 ▯ file descriptors can have different io ▯ cycle through all the file descriptors to find when was the activity. – use for loop to cycle through the fd ▯ when activity is received server_socket, ▯ ▯ Endianess  Different architectures use diff byte orderings internally for their multi-byte databytes  ****LOOK AT RECITATION SLIDES******** ▯ store highest byte first, b4 -> b3 -> b2 -> b1 Little endian ▯ b1 -> b2 -> b3 -> b4 Big endian ▯ TO FIX PROBLEM, whenever you send data, you have to make sure you send it by choosing either one endianess (whether you store the largest byte at first index or end index) ▯ Network byte-order is big-endian – ▯ NEED TO CONVERT ALL DATA TO NETWORK BYTE_ORDER BEFORE SENDING OVER A LINK ▯ Htons() host to network short ▯ Htonl() host to network long ▯ Ntohs() network to host short ▯ Ntohl() network to host long multi-byte integers ▯ ▯ BONUS ASSIGNMENT: P2P File Transfer  Additional functionality to transfer files between clients o Direct transfer between clients, no SERVER involved o Binary and text files o Open a TCP connection between given two clients o NO broadcast file transfers ▯ ▯ 2/9/16 Lecture ▯ Chapter 2: 2.1 – principles of network applications ▯ Application layer ▯ ▯ ▯ Ex. network apps – e-mail, web, text messaging, etc ▯ Creating a network app ▯ - write programs that:  run on (different) end systems  communicate over network  eg. Web server software communicates with browser software ▯ - no need to write software for network-core devices  network-core devices do not run user applications  applications on end systems allows for rapid app development, propagation ▯ Application architectures  1) Client-server  2) Peer-to-peer  3) Hybrid of client-server and P2P ▯ 1) Client-server architecture  Server o Always-on host o Permanent IP address o Data centers for scaling  Clients o Communicate with server o May be intermittently connected o May have dynamic IP addresses o Do not communicate directly WITH each other ▯ 2) P2P architecture  no always-on server  arbitrary end systems directly communicate  peers request service from other peers, provide service in return to other peers o self scalability – new peers being new service capacity, as well as new service demands o Bandwidth is high, a lot of pressure on ISP’s, ISP tries to block P2P traffic o Problems: Incentive, Management, P2P traffic  peers are intermittently connected and change IP addresses o complex management 3) Hybrid of client-server and P2P - Skype- voice over IP P2P application, centralized server: finding address of remote party, client-client connection: direct (not through server) - Instant Messaging  chatting between two users is P2P  centralized service: client presence detection / location o user registers its IP address with central server when it comes online o user contacts central server to find IP addresses of buddies o ▯ *****OUR PROJECT IS client-server mainly. If you attempt bonus assignment with file transfer which is P2P , it makes the assignment HYBRID** ▯ ▯ Processes communicating ▯ - process: program running with a host  within same host, two processes communicate using inter-process communication (defined by OS)  processes in different hosts communicate by exchanging messages  aside: applications with P2P architectures have client processes & server processes ▯ - client process: process that initiates communication ▯ - server process: process that waits to be contacted ▯ ▯ Sockets ▯ - process sends/receives messages to/from its socket (example. A door that opens to let you send message out) ▯ - socket analgous to door  sending process shoves message out door  sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process ▯ - API: (1) choice of transport protocol ▯ (2) ability to fix a few parameters ▯ ▯ Addressing processes ▯ - to receive messages, process must have identifier ▯ - host device has unique 32-bit IP address ▯ - Question: does IP address of host on which process runs suffice for identifying the process?  Answer – no, many processes can be running on same host ▯ - identifier includes IP address and port numbers associated with process on host ▯ - ex. port numbers: HTTP server: 80, mail server: 25 ▯ - to send HTTP message to web server:  IP address:  Port number: 80 ▯ ▯ App-layer protocol defines ▯ - types of messages exchanged eg. Request, response ▯ - message syntax – what fields in messages & how fields are delineated (ex. how many bytes each field is?) ▯ - message semantics – meaning of information in fields ▯ - rules for when and how processes send & respond to messages ▯ - open protocols:  defined in RFC’s  allows for interoperability  eg. HTTP, SMTP ▯ - proprietary protocols: eg. Skype ▯ ▯ What transport service does an app need? ▯ - data loss  some apps (eg. File transfer, web transactions) require 100% reliable data transfer  other apps eg. Audio can tolerate some loss ▯ - timing  some apps (eg. Internet telephony, interactive games) require low delay to be “effective” ▯ - throughput - rate(bits/time unit) at which bits transferred between sender/receiver – requires a certain bandwidth  some apps (eg. Streaming Multimedia, videos) require minimum amount of throughput to be “effective”  -other apps (“elastic apps”) make use of whatever throughput they get ▯ - security – encryption, data integrity, …. ▯ ▯ ▯ ▯ Internet transport protocols services ▯ TCP service:  Connection-oriented: setup required between client and server processes  Reliable transport: between sending and receiving process  Flow control: sender won’t overwhelm receiver  Congestion control: throttle sender when network overloaded (deals with internet)  Does not provide: timing, minimum throughput guarantee, security ▯ UDP service:  Unreliable data transfer between sending and receiving process  Does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup ▯ Q: why bother? Why is there a UDP? ▯ - it’s fast and you can build transport layers/access servers on top of UDP. ▯ ▯ ▯ ▯ Video needs TCP because it’s afraid of UDP traffic and it is blocked. Only choice to work is TCP then!! ▯ Socket programming ▯ -Goal: learn how to build client/server application that communicate using sockets ▯ - Socket API - introduced in UNIX, 1981  explicitly created, used, released by apps  two types of transport service via socket API: o unreliable datagram o reliable, byte stream-oriented ▯ - socket: a host-local application-created, OS-controlled interface (a “door”) into which an application process can both send and receive messages to/from another application process ▯ ▯ Socket ▯ - Socket Family  PF_INET denotes Internet family  we’re interested in this for class (used interchangeably with AF_INET, the same thing but less obsolete)  PF_UNIX denotes Unix pipe facility  PF_PACKET denotes direct access to the network interface (ie. It bypasses the TCP/IP protocol stack) ▯ - Socket Type  SOCK_STREAM is used to denote a byte stream  SOCK_DGRAM is an alternative that denotes a message oriented service, such as that provided by UDP ▯ Socket-programming using TCP ▯ Socket – a door between application process and end-end transport protocol (UCP or TCP) ▯ TCP service: reliable transfer of bytes from one process to another ▯ ▯ - Client must contact server!!  Server process must first be running and must have created socket (door) that welcomes client’s contact ▯ - Client contacts server by:  creating client-local TCP socket  specifying IP address, port number of server process  when client creates socket: client TCP establishes connection to server TCP  when contacted by client, server TCP creates new socket for server process to communicate with client o allows server to talk with multiple clients o source port numbers used to distinguish clients ▯ - application viewpoint: TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server ▯ ▯ Stream jargon ▯ - stream is a sequence of bytes that flow into or out of a process ▯ - input stream is attached to some inport source for the process eg. Keyboard or socket ▯ - output stream is attached to an output source eg. Monitor or socket. ▯ ▯ TCP Client/Server Socket Interaction ▯ ▯ **** IMPORTANT **** WILL BE QUESTION 3 of THE EXAM ^^^^^^ know how it works ▯ you need at least two sockets for a server  One for other servers to connect  One that is created for the client to connect to that is on the same server port number ▯ Creating a Socket ▯ ▯ Client-Server Model with TCP ▯ SERVER SIDE ▯ ▯ - Bind  Binds the newly created socket to the specified address ie. The network address of the local participant (the server)  Address is a data structure which combines IP and port ▯ - Listen  Defines how many connections can be pending on the specified socket - Accept  Carries out the passive open  Blocking operation o Does not return until a remote participant has established a connection o When it does, it returns a new socket that corresponds to the new established connection and the address argument contains the remote participant’s address ▯ - Select – notifies/monitors what is happening with your socket, and be notified when something arrives ▯ ▯ CLIENT SIDE ▯ -client  Applications performs active open  IT says who it wants to communicate with ▯ - Client invokes int connect (int socket, struct sockaddr *address, int addr_len) ▯ - Connect  Does not return until TCP has successfully established a connection at which application is free to begin sending data  Address contains remote machine’s address ▯ ▯ ▯ TCP guarantees the package to be sent in the same order (these two functions above can change the number of bytes sent) ▯ ▯ Ex. Application: Client ▯ ▯ ▯ ▯ Ex. Application: Server ▯ ▯ ▯ ▯ Socket Programming with UDP (FOR OUR PROGRAMMING ASSIGNMENT 3) ▯ UDP: no “connection” between client & server  No handshaking before sending data  Sender explicitly attaches IP destination address and port # to each packet  Receiver extracts sender IP address and port # from received packet ▯ UDP: transmitted data may be lost or received out-of-order ▯ Application viewpoint:  UDP provides unreliable transfer of groups of bytes (“datagram’s”) between client and server   int sentto (int socket, char *msg, int msg_len, int flags, const struct sockaddr *dest_addr, socklen_t dest_len)   int recv (int socket, char *buff, int buff_len, int flags, const struct sockaddr, *src_addr, socklen_t, src_len) ▯ ▯ ▯ ▯ ▯ 2/11/16 Lecture (Week 3 Thursday) ▯ Chapter 2.2 – Web and HTTP ▯ - A webpage consists of objects (ex. HTML file, JPEG image, Java applet, audio file ▯ - Consists of base HTML-file which includes several referenced objects ▯ - Each object is addressable by a URL (separated by hostname and pathname) ▯ ▯ ▯ HTTP Overview ▯ HTTP: hypertext transfer protocol ▯ - Web’s application layer protocol ▯ - client/server model  client: browser that requests, receives, (using HTTP protocol) and displays “Web” objects  server: web server sends (using HTTP protocol) objects in response to requests ▯ uses TCP:  client initiates TCP connection (creates socket) to server, port 80  server accepts TCP connection from client  HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)  TCP connection closed ▯ HTTP is “stateless” – server maintains no info about past client requests ▯ ▯ Protocols that maintain “state” are COMPLEX! ▯ - past history (state) must be maintained ▯ - if server/client crashes, their views of “state” may be inconsistent, must be reconciled ▯ ▯ HTTP connections ▯ Non-persistent HTTP: ▯ - at most one object sent over TCP connection, then closed ▯ - downloading multiple objects required multiple connections ▯ Persistent HTTP: ▯ - multiple objects can be sent over single TCP connection btw client n server ▯ ▯ ▯ Non-persistent HTTP: response time ▯ - for small packets, you ignore response time ▯ ▯ ▯ RTT = roundtrips ▯ ▯ LOOK AT NOTES for 2/11/16 ▯ ON MIDTERM TEST / EXAM QUESTION # 4 and possible on final ▯ Ttotal = ▯ 2RTT + dtr + 10 (2RTT + dtr) // non-persistent HTTP w/o parallel connec ▯ 2RTT + dtr + 2RTT + 10dtr //non-persistent HTTP w/ parallel connec ▯ 2RTT + dtr + 10(RTT + dtr) //persistent HTTP w/o pipelining ▯ 2RTT + dtr + RTT + 10dtr //persistent HTTP w/ pipelining ▯ ▯ - cutting down roundtrip times / response times ▯ Persistent HTTP ▯ ▯ Benefits of Persistent HTTP ▯ - reduced response time ▯ - CPU time saved in routers and hosts ▯ - Network congestion is reduced ▯ - HTTP requests and responses can be pipelined on a connection  As little as one RTT for all the referenced objects ▯ Issues with Persistent HTTP ▯ - How long to keep a TCP connection open?  TCP connections require memory  Many TCP connections can overload server  Server timeouts and closes connections ▯ - If disk is the bottleneck, persistent HTTP may perform worse than non-persistent HTTP (see paper) – not enough space in memory ▯ Issues with Pipelining? ▯ - Some browsers do not implement pipelining  IE, Safari: NO; Opera, Chrome: YES; Firefox: YES but OFF by default -------- Pipelining is GOOD*  Reasons? Old servers may not implement it; head of line blocking (order of requests are sent, if large objects is sent first, it blocked everything else) ▯ ▯ SPDY – An Enhancement to HTTP (work with HTTP) / 1.1  Proposed by Google; deployed and used by Google, Fb, Twitter, etc  4 key design features: 1) Single TCP connection – can change order of request, 2) Request prioritization, 3) Server push, 4) Header compression  Speed up to 10-50%; should be better than HTTP except when some object size is large ▯ HTTP request message (not tested) ▯ - two types of HTTP messages: request, response - in ASCII - requestline (specify method: GET, POST, HEAD; , - header lines (host location, browser type, format to accept, keep-alive connection at a line) (bigger the header line, bigger the message) Uploading form input - POST method: webpage often includes form input; input is uploaded to server in entity body - URL method: uses GET method; input is uploaded in URL field of request line: - HEAD: asks server to leave requested object out of response HTTP response message (not tested) User-server state: cookies Many Websites use cookies and there are 4 components: 1) cookie header line of HTTP response message 2) cookie header line in next HTTP request message 3) cookie file kept on user’s host, managed by user’s browser 4) back-end database at website ex. Susan always access Internet from PC. She visits Amazon for first time. When initial HTTP request arrives at set, site creates: unique ID, entry in backend database for ID Cookies can show authorization, shopping carts, recommendations, advertising, remembers the user’s credit card, user session state (Web email) - How to keep “state”: o Protocol endpoints: maintain state at sender/receiver over multiple transactions o Cookies: http messages carry state ▯ - Cookies and privacy  cookies permit sites to learn a LOT about you  you might supply name and email to sites  Web caches (proxy server) Goal: satisfy client request without involving origin server Client CONTACTS proxy server first, then proxy server sends to origin server - user sets browser: web accesses via cache - browser sends all HTTP requests to cache o object in cache: cache returns object o else cache requests object from origin server, then returns object to client  ▯ - cache acts as both client and server: server for original requesting client; client to origin server ▯ - typically cache is installed by ISP ▯ - WHY web caching?  Reduce response time for client request  Reduce traffic on an institution’s access link  Internet dense with caches: enables “poor” content providers to effectively deliver content ▯ Don’t have to go straight to origin server and use a lot of bandwidth ▯ Utilization = traffic intensity = incoming rate / outgoing rate ▯ ▯ total delay = 2 sec + 0.97% + usecs reduce delay from MINUTES to seconds Conditional GET - Goal: don’t send object if cache has up-to-date cached version o No object transmission delay o Lower link utilization ▯ - cache: specify date of cached copy in HTTP request  if-modified-since: <date> ▯ - server: response contains no object if cached copy is up-to- date:  HTTP/1.0 304 NOT MODIFIED ▯ ▯ ▯


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Jennifer McGill UCSF Med School

"Selling my MCAT study guides and notes has been a great source of side revenue while I'm in school. Some months I'm making over $500! Plus, it makes me happy knowing that I'm helping future med students with their MCAT."

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.