Project 2: A P2P Chat Application Review Ananth Rao.

Slides:



Advertisements
Similar presentations
Lab tutorial Lab assignment 2 Fall 2006
Advertisements

CCNA – Network Fundamentals
Intermediate TCP/IP TCP Operation.
Guide to TCP/IP, Third Edition
Project 2 Review (Part 2) Ananth Rao. Overview Stabilize and Notify Join (slides stolen from lecture) Coding Trivia Bootstrapping and debugging.
Communication Protocols II Ninth Meeting. TCP/IP family.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 OSI Transport Layer Network Fundamentals – Chapter 4.
Socket Programming.
TDC561 Network Programming Camelia Zlatea, PhD Week 2 – part II: Socket Application Programming Interface.
UDP: User Datagram Protocol. UDP: User Datagram Protocol [RFC 768] r “bare bones”, “best effort” transport protocol r connectionless: m no handshaking.
TCP/IP Protocol Suite 1 Chapter 11 Upon completion you will be able to: User Datagram Protocol Be able to explain process-to-process communication Know.
2: Application Layer 1 Chapter 2 Application Layer Computer Networking: A Top Down Approach, 5th edition. Jim Kurose, Keith Ross Addison-Wesley, April.
Lecture 8 UDP Sockets & I/O Multiplexing
EEC-484/584 Computer Networks Lecture 6 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
Gursharan Singh Tatla Transport Layer 16-May
TRANSPORT LAYER T.Najah Al-Subaie Kingdom of Saudi Arabia Prince Norah bint Abdul Rahman University College of Computer Since and Information System NET331.
Socket Programming References: redKlyde ’ s tutorial set Winsock2 for games (gamedev.net)
TCP/IP Protocol Stack IP Device Drivers TCPUDP Application Sockets (Gate to network) TCP: –Establish connection –Maintain connection during the communication.
Assignment 3 A Client/Server Application: Chatroom.
University of Calgary – CPSC 441.  UDP stands for User Datagram Protocol.  A protocol for the Transport Layer in the protocol Stack.  Alternative to.
Chapter 17 Networking Dave Bremer Otago Polytechnic, N.Z. ©2008, Prentice Hall Operating Systems: Internals and Design Principles, 6/E William Stallings.
TCP/IP Essentials A Lab-Based Approach Shivendra Panwar, Shiwen Mao Jeong-dong Ryoo, and Yihan Li Chapter 5 UDP and Its Applications.
Server Sockets: A server socket listens on a given port Many different clients may be connecting to that port Ideally, you would like a separate file descriptor.
Fundamentals of Computer Networks ECE 478/578 Lecture #19: Transport Layer Instructor: Loukas Lazos Dept of Electrical and Computer Engineering University.
Transport Layer Moving Segments. Transport Layer Protocols Provide a logical communication link between processes running on different hosts as if directly.
Review: How to create a TCP end point? What is the right format for sin_port and sin_addr in the sockaddr_in data structure? How many different ways we.
Chapter 15 – Part 2 Networks The Internal Operating System The Architecture of Computer Hardware and Systems Software: An Information Technology Approach.
Socket Programming Lec 2 Rishi Kant. Review of Socket programming Decide which type of socket – stream or datagram. Based on type create socket using.
Networking Tutorial Special Interest Group for Software Engineering Luke Rajlich.
CS 158A1 1.4 Implementing Network Software Phenomenal success of the Internet: – Computer # connected doubled every year since 1981, now approaching 200.
CPSC 441 TUTORIAL – FEB 13, 2012 TA: RUITNG ZHOU UDP REVIEW.
Distributed Computing A Programmer’s Perspective.
CSCE 515: Computer Network Programming UDP Socket Wenyuan Xu Department of Computer Science and Engineering.
Introduction to Socket
Sockets Socket = abstraction of the port concept: –Application programs request that the operating system create a socket when one is needed –O.S. returns.
1 Transport Protocols Relates to Lab 5. An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
2: Application Layer1 Chapter 2: Application layer r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail  SMTP,
Programming with UDP – II Covered Subjects: Creating UDP sockets Client Server Sending data Receiving data Connected mode.
CSCI 330 UNIX and Network Programming Unit XV: Transmission Control Protocol.
Today’s topic: UDP Reliable communication over UDP.
Review: – Why layer architecture? – peer entities – Protocol and service interface – Connection-oriented/connectionless service – Reliable/unreliable service.
CSCI 330 UNIX and Network Programming Unit XIV: User Datagram Protocol.
Transport Protocols.
Project 3 Overview Spring 2010 Recitation #9.
Socket Programming. Computer Science, FSU2 Interprocess Communication Within a single system – Pipes, FIFOs – Message Queues – Semaphores, Shared Memory.
4343 X2 – The Transport Layer Tanenbaum Ch.6.
1 Computer Communication & Networks Lecture 23 & 24 Transport Layer: UDP and TCP Waleed Ejaz
Networking (Cont’d). Congestion Control l Is achieved by informing nodes along a route that congestion has occurred and asking them to reduce their packet.
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
2: Transport Layer 11 Transport Layer 1. 2: Transport Layer 12 Part 2: Transport Layer Chapter goals: r understand principles behind transport layer services:
Socket Programming in C CS587x Lecture 3 Department of Computer Science Iowa State University.
Process-to-Process Delivery:
Socket Programming(1/2). Outline  1. Introduction to Network Programming  2. Network Architecture – Client/Server Model  3. TCP Socket Programming.
Represented BY:- Allauddin Ahmad.  What it is?  OSI model.  History.  Objectives.  Encapsulation and decapsulation.  Multiplexing and demultiplexing.
1 Socket Interface. 2 Basic Sockets API Review Socket Library TCPUDP IP EthernetPPP ARP DHCP, Mail, WWW, TELNET, FTP... Network cardCom Layer 4 / Transport.
UDP. User Datagram Protocol (UDP)  Unreliable and unordered datagram service  Adds multiplexing  No flow control  Endpoints identified by ports 
1 UDP Sockets Programming Creating UDP sockets.Creating UDP sockets. –Client –Server Sending data.Sending data. Receiving data.Receiving data. Connected.
SOCKET PROGRAMMING Presented By : Divya Sharma.
Chapter 9: Transport Layer
Assignment 3 A Client/Server Application: Chatroom
Instructor Materials Chapter 9: Transport Layer
Transport Protocols Relates to Lab 5. An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
CS 1652 Jack Lange University of Pittsburgh
Process-to-Process Delivery, TCP and UDP protocols
TCP Transport layer Er. Vikram Dhiman LPU.
Review: TCP Client-Server Interaction
Transport Protocols Relates to Lab 5. An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
Transport Protocols Relates to Lab 5. An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
UDP Sockets Programming
Transport Protocols An overview of the transport protocols of the TCP/IP protocol suite. Also, a short discussion of UDP.
Presentation transcript:

Project 2: A P2P Chat Application Review Ananth Rao

Overview In this project, you will build a Peer-to-Peer chat application –Good News: Only one program need to be written –Bad News: The single program is considerably more complex because it does the job of both the client and the server, and it uses UDP Feel free to interrupt with questions

Overlay Networks Network –defines addressing, routing, and service model for communication between hosts Overlay network –A network built on top of one or more existing networks –adds an additional layer of indirection/virtualization –changes properties in one or more areas of underlying network

P2P Networking Each participant (user of the chat application in this case) is a “peer” and plays an identical role in the system Users co-operatively build the service without relying on a third party to run a server –Instead of the “control” being centralized at a server, it is distributed amongst all the users –The users must trust each other at some level to be able to do this Examples: Gnutella, FastTrack, Chord, CAN

Other key differences from Project 1 No “multicast” of messages Have to use UDP sockets –You must learn how to program with UDP sockets –You must implement timers and retransmission of lost packets Must be able to recover from failure –Program is “killed” by a signal –Network cable is disconnected

Programming with UDP Sockets (Create a Socket) int udpSock = socket(AF_INET, SOCK_DGRAM, 0); if(udpSock < 0) perror(“Call to socket failed”); UDP sockets a symmetric (no distinction between a server socket and a client socket) You must SOCK_DGRAM instead of SOCK_STREAM You cannot use “connect” on a datagram (UDP) socket “udpSock” is the file descriptor There is no single destination associated with a UDP socket, so each “peer” uses only one UDP socket

Bind Socket to a Port sockaddr_in localAddr; bzero(&localAddr, sizeof(localAddr)) localAddr.sin_family = AF_INET; localAddr.sin_port = htons(localPort); localAddr.sin_addr.s_addr = INADDR_ANY; int retVal = bind(udpSock, (sockaddr*)&localAddr, sizeof(localAddr)); // check retVal for errors Similar to “bind” used for a server TCP socket The localPort to be used is given through the command line for each chatpeer

Send Packets sockaddr_in toSockAddr; bzero(&toSockAddr, sizeof(toSockAddr)); toSockAddr.sin_family = AF_INET; toSockAddr.sin_addr.s_addr = toAddr; toSockAddr.sin_port = htons(toPort); int retVal = sendto(udpSock, packetBuf, packetLen, 0, (sockaddr*) toSockAddr, sizeof(toSockAddr)); // check retVal for errors Each packet is individually addressed to a destination address and port (retVal == packetLen) doesn’t guarantee anything at all

Receive Packets sockaddr_in fromSockAddr; bzero(&fromSockAddr, sizeof(fromSockAddr)); socklen_t fromLen = sizeof(fromSockAddr); int retVal = recvfrom(udpSock, packetBuf, MAXBUFFERSIZE, 0, (sockaddr*) &fromSockAddr, &fromLen); Can receive a packet from any other chatpeer program on the same socket The address of the sender is available in “fromSockAddr”

Programming with Timers struct timeval currTime, mlpTimeout, ackDueTime; gettimeofday(&currTime, NULL); mlpTimeout.tv_sec = MLP_TIMEOUT/1000; mlpTimeout.tv_usec = (MLP_TIMEOUT%1000)*1000; timeradd(&currTime, &mlpTimeout, &ackDueTime); “struct timeval” has two fields: “tv_sec” (seconds) and “tv_usec” (microseconds) The macros “timeradd” and “timersub” are defined in “sys/time.h” timercmp(&a, &b, CMP) may be used too, where CMP is a binary comparison operator (, =,==)

Finding the address of the machine the program is running on stuct utsname myName; int retVal = uname(&myName); // check retVal struct hostent *localHost = gethostbyname (myName.nodename); // check localHost != NULL myAddr = (*(unsigned long *) localHost->h_addr_list[0]); The local address is included in the header of some packets.

Using select with timeouts To implement fine grained timers, you must find the earliest time at which the next event has to occur struct timeVal nextEventTime = getNextTime(); struct timeVal currTime, waitTime; gettimeofday(&currTime, NULL) timersub(&nextEventTime, &currTime, &waitTime); int retVal = select(maxFd+1, &readSet, NULL, NULL, &waitTime); “readSet” will contain “udpSock” and “stdin”

Structure of your Program (ORL and ML) We think of the program as comprising two layers, the Messaging Layer and the Overlay Routing Layer

Why two layers? Because it a natural way to think about the program Because it is a good way to think about and organize your program Because it is easier to write the specs this way Hopefully, this project will help you understand layering concepts better Not for standardization, multiplexing, demultiplexing or for other programs to use the ORL

ORL: High level description Route a packet from end-to-end on the overlay Maintain the topology of the overlay Recover from failures of nodes on the overlay Provide best-effort packet forwarding service

ML: High level description Deal with user input and output Use the services provided by the ORL to send packets to other users Implement retransmissions and timeouts

Addressing in ORL (Hash function) Addressing in the ORL is in terms of 32-bit identifier (similar to IP addresses) Addressing in the ML is in terms of the userName (similar to FQDNs) We use a simple hash function to map userNames to identifiers (as opposed to a mapping mechanism like DNS)

The Overlay Topology

successorNode(x) explained

Packet Forwarding Algorithm WrapBetween(l,h,x) if (l < h) return ((x > l) and (x < h)) else return ((x > l) or (x < h)) Forward(packet, destinationId) if ((destinationId = NodeId) OR WrapBetween(predecessorNode.NodeId, NodeId, destinationId)) stripORLHeader(packet) HandleMLPPacket(packet) else send(packet, successorNode.address, successorNode.port)

ML Packet Types MLP_MESSAGE MLP_CHECK MLP_NACK MLP_ACK

ORL Header Format You don’t have to implement the ORL control packets for the check point!!

How routing works for MESG and ACK

Retransmissions, Timeouts, Past History What happens if the ACK is lost and the message is retransmitted? To avoid printing the same message twice, we have maintain a window of the past history

Beyond the Checkpoint You have to implement Stabilize, Notify and Join Give yourselves a lot of time to debug (more so for the part after the check point!!) Need another review?? Sample binaries??