Unit-3

Unit-3TCP/IP Model, BSD Sockets Overview, TCP Sockets and Client/Server, UDP Sockets and Client/Server, Out of Band Data, Raw Sockets, PING & TRACEROUTE Programs, Routing, Multicasting using UDP Sockets

TCP/IP MODELTCP/IP MODELA set of protocols allowing communication across diverse networksThere are four layers of the TCP/IP reference model.Standards area available in the form of RFC documents-Request For Comments (RFC)Standards are overseen by the Internet Engineering Task Force (IETF)

ApplicationLayerTransportLayerInternetLayerNetworkInterfaceApplicationLayerTransportLayerInternetLayerNetworkInterface(a)(b)TCP/IP Network ArchitectureTCP/IP model does not require strict layering

Application layer

Provide services that can be used by other applicationsIncorporate the functions of top 3 OSI layers E.g., HTTP protocol, format in request, dialogue between client and server

Transport layer

Application layer directly run over the transport layer, corresponding to OSI transport layer.Two kinds of services: TCP & UDP.TCPTransmission Control Protocol, reliable connect-oriented transfer of a byte stream.UDPUser Datagram Protocol, best-effort connectionless transfer of individual messages.ApplicationTransportInternetNetwork InterfaceApplicationTransportInternet Network InterfaceInternet Network InterfaceNetwork 1Network 2Machine AMachine BRouter/Gateway Internet layer Transfer of information across networks through gateways/routersCorresponding to OSI network layer: routing and congestion controlGlobal unique IP address and IP packetsBest-effort connectionless IP packet transfer: no setup, routed independently, robust, out of order, duplicate, or lose of packetApplicationTransportInternetNetwork InterfaceApplicationTransportInternet Network InterfaceInternetNetwork InterfaceSNetwork 1Network 2Machine AMachine BRouter/GatewayNetwork interface layerConcerned with network-specific aspects of the transfer of packetsCorresponding to part of OSI network layer and data link layerDifferent network interfaces: X.25, ATM, frame relay, Ethernet, etc IP packetPacketof network1Packetof network1IP packetIP packetPacketof network2IP packetPacketof network2

The Procedure Executed at Routers1. Router receives a frame from one network (e.g., N1) through its physical layer2. The data link entity for N1 extracts the IP packet from the frame and passes the IP packet up to its network entity.3. The network entity checks destination IP address (finds the packet is not for itself) and determines the next hop based on destination IP address (i.e., routing) , this next hop router will be in another network (e.g. N2)4. Network entity passes the IP packet down to the data link entity for N2 5. Data link entity for N2 encapsulates the IP packet in a frame of N2 and passes the frame down to physical layer for transmission to the next router through network N2.BSD SOCKETBSD SocketsThe Berkeley Sockets 4.4 API (Applications Programmer Interface) is a set of standard function calls made available at the application level. These functions allow programmers to include Internet communications capabilities in their products.

BSD Sockets generally relies upon client/server architecture. For TCP communications, one host listens for incoming connection requests. When a request arrives, the server host will accept it, at which point data can be transferred between the hosts. UDP is also allowed to establish a connection, though it is not required. Data can simply be sent to or received from a host.BSD SocketsThe Berkeley Sockets API (also frequently referred to as simply `sockets') was originally released with 4.2BSD in 1983. Enhancements have continued through the 4.4BSD systems.

The Berkeley Sockets API (also frequently referred to as simply `sockets') was originally released with 4.2BSD in 1983. Enhancements have continued through the 4.4BSD systems. Berkeley based code can be found in many different operating systems, both commercial and public domain, such as BSD/OS, FreeBSD, NetBSD, OpenBSD, and UnixWare 2.x.BSD SocketsOther sockets APIs exist, though Berkeley Sockets is generally regarded as the standard. Two of the most common APIs are Winsock and TLI. Winsock (Windows Sockets) was developed for the Microsoft Windows platform in 1993, and is based significantly on the BSD interface. A large subset of the BSD API is provided, with most of the exceptions being platform specific to BSD systems. TLI (Transport Layer Interface) was developed by AT&T, and has the capability to access TCP/IP and IPX/SPX transport layers. XTI (X/Open Transport Interface, developed by X/Open Company Ltd.) is an extension of TLI that allows access to both TCP/IP and NetBios.Common Socket Callssocket()A socket, in the simplest sense, is a data structure used by the Sockets API. When the user calls this function, it creates a socket and returns reference a number for that socket. That reference number, in turn, must be used in future calls.bind()This call allows a user to associate a socket with a particular local port and IP address. In the case of a server (seelistenandacceptbelow), it allows the user to specify which port and IP address incoming connections must be addressed to. For outgoing connection requests (seeconnectbelow), it allows the user to specify which port the connection will come from when viewed by the other host.

Common Socket Callslisten()This function prepares the given socket to accept incoming TCP requests. It must be called beforeaccept().connect()When a user issues aconnectcommand, the stack creates a connection with another host. Beforeconnectcan instruct the stack to establish a connection, the user must pass a socket and asockaddr_instructure containing the destination IP address and port. In TCP, an actual connection is negotiated. In UDP, however, no packets are exchanged.send()This call allows a user to send data over a connected socket. Unlikesendto(), this socket must be connected. Because the socket is already connected, it is not necessary to specify the destination address (the destination address was set inacceptorconnect).sendcan be used for either UDP or TCP data.

Common Socket Callssendto()Unlikesend(),sendtorequires users to specify the destination port and address. This is useful for UDP communications only, as TCP requires a pre-existing connection. sendto may be used on either connected or unconnected UDP sockets.recv()This function allows the user to receive data on the connected socket.recvcan be used for either TCP or UDP.recvfrom()This function allows the user to receive data from a specified UDP socket (whether or not it is connected).It may not be used for TCP sockets, as they require a connection.close()This function closes (read: deletes) a socket that has been allocated with the socket call. If the socket is connected, it closes the connection before deleting it. Because the close call is frequently used for more than one purpose (closing open files, for example), it is renamed tfClose() in the Treck stack to avoid conflicts with the preexisting function.TCP SOCKET AND CLIENT/SERVERSockets

Client socket, welcoming socket (passive) and connection socket (active)JAVA TCP Socketsjava.net.SocketImplements client sockets (also called just sockets).An endpoint for communication between two machines.Constructor and MethodsSocket(String host, int port): Creates a stream socket and connects it to the specified port number on the named host.InputStream getInputStream()OutputStream getOutputStream()close()

java.net.ServerSocketImplements server sockets.Waits for requests to come in over the network.Performs some operation based on the request.Constructor and MethodsServerSocket(int port)Socket Accept(): Listens for a connection to be made to this socket and accepts it. This method blocks until a connection is made.Socket programming with TCPExample client-server app:client reads line from standard input (inFromUser stream) , sends to server via socket (outToServer stream)server reads line from socketserver converts line to uppercase, sends back to clientclient reads, prints modified line from socket (inFromServer stream)

Input stream: sequence of bytesinto processoutput stream: sequence of bytes out of processClientprocessclient TCP socketClient/server socket interaction: TCPwait for incomingconnection requestconnectionSocket =welcomeSocket.accept()create socket,port=x, forincoming request:welcomeSocket = ServerSocket()create socket,connect to hostid, port=xclientSocket = Socket()closeconnectionSocketread reply fromclientSocketcloseclientSocketServer (running on hostid)Clientsend request usingclientSocketread request fromconnectionSocketwrite reply toconnectionSocketTCP connection setupsocket()int socket(int family, int type, int protocol);Create a socket, giving access to transport layer service.family is one ofAF_INET (IPv4), AF_INET6 (IPv6), AF_LOCAL (local Unix),AF_ROUTE (access to routing tables), AF_KEY (new, for encryption)type is one ofSOCK_STREAM (TCP), SOCK_DGRAM (UDP)SOCK_RAW (for special IP packets, PING, etc. Must be root)setuid bit (-rws--x--x root 1997 /sbin/ping*)protocol is 0 (used for some raw socket options)upon success returns socket descriptorInteger, like file descriptorReturn -1 if failurebind()sockfd is socket descriptor from socket()myaddr is a pointer to address struct with:port number and IP addressif port is 0, then host will pick ephemeral portnot usually for server (exception RPC port-map)IP address != INADDR_ANY (unless multiple nics) addrlen is length of structurereturns 0 if ok, -1 on errorEADDRINUSE (Address already in use)int bind(int sockfd, const struct sockaddr *myaddr, socklen_t addrlen);Assign a local protocol address (name) to a socket.listen()sockfd is socket descriptor from socket()backlog is maximum number of incomplete connectionshistorically 5rarely above 15 on a even moderate Web server!Sockets default to active (for a client)change to passive so OS will accept connectionint listen(int sockfd, int backlog);Change socket state for TCP server.accept()sockfd is socket descriptor from socket()cliaddr and addrlen return protocol address from clientreturns brand new descriptor, created by OSnote, if create new process or thread, can create concurrent serverint accept(int sockfd, struct sockaddr cliaddr, socklen_t *addrlen);Return next completed connection.close()sockfd is socket descriptor from socket()closes socket for reading/writingreturns (doesnt block)attempts to send any unsent datasocket option SO_LINGERblock until data sentor discard any remaining datareturns -1 if errorint close(int sockfd); Close socket for use.Sending and Receivingint recvfrom(int sockfd, void *buff, size_t mbytes, int flags, struct sockaddr *from, socklen_t *addrlen);int sendto(int sockfd, void *buff, size_t mbytes, int flags, const struct sockaddr *to, socklen_t addrlen);Same as recv() and send() but for addrrecvfrom fills in address of where packet came fromsendto requires address of where sending packet toTCPClient.javaimport java.io.*; import java.net.*;

class TCPClient { public static void main(String argv[]) throws Exception{ String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());TCPClient.javaBufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } TCPServer.javaimport java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) {

Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); TCPServer.java DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); } } } UDP SOCKET AND CLIENT/SERVERUDP SocketsDatagramSocket class

DatagramPacket class needed to specify the payloadincoming or outgoingSocket Programming with UDP UDPConnectionless and unreliable service.There isnt an initial handshaking phase.Doesnt have a pipe.transmitted data may be received out of order, or lost

Socket Programming with UDPNo need for a welcoming socket.No streams are attached to the sockets.the sending hosts creates packets by attaching the IP destination address and port number to each batch of bytes.The receiving process must unravel to received packet to obtain the packets information bytes.JAVA UDP SocketsIn Package java.netjava.net.DatagramSocketA socket for sending and receiving datagram packets.Constructor and MethodsDatagramSocket(int port): Constructs a datagram socket and binds it to the specified port on the local host machine.void receive( DatagramPacket p)void send( DatagramPacket p)void close()Example: Java client (UDP)

Output: sends packet (TCP sent byte stream)Input: receives packet (TCP received byte stream)Clientprocessclient UDP socketClient/server socket interaction: UDPcloseclientSocketServer (running on hostid)read reply fromclientSocketcreate socket,

clientSocket = DatagramSocket()ClientCreate, address (hostid, port=x,send datagram request using clientSocketcreate socket,port=x, forincoming request:serverSocket = DatagramSocket()read request fromserverSocketwrite reply toserverSocketspecifying clienthost address,port umberUDPClient.javaimport java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); UDPClient.java DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } }UDPServer.javaimport java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); String sentence = new String(receivePacket.getData()); UDPServer.java InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket);

} }}

Socket functional callssocket (): Create a socketbind(): bind a socket to a local IP address and port #

listen(): passively waiting for connectionsconnect(): initiating connection to another socketaccept(): accept a new connection

Write(): write data to a socketRead(): read data from a socketsendto(): send a datagram to another UDP socketrecvfrom(): read a datagram from a UDP socket

close(): close a socket (tear down the connection)OUT OF BAND DATAIntroductionOut-of-band dataExpedited dataNotification should be sent before any normal (in-band) data that is already queued to be sentHigher priority than normal dataOut-of-band data mapped onto existing connection (instead of using two connections)UDP has no implementation of out-of-band dataTCP has its own flavor of out-of-band dataTCP Out-of-Band DataTCP does not have a true out-of-band data modeTCP provides an urgent modeN bytes in TCP socket send bufferProcess writes a single byte of out-of-band data send (fd,a,1,MSG_OOB);

1NFirst byte to sendlast byte to sendSocket send buffer1NOOBSocket send bufferFirst byte to sendlast byte to sendTCP Urgent PointerTCP Out-of-Band Data 2/5Next segment sent by TCP will have URG flag set in TCP headerUrgent offset in TCP header points to byte following the out-of-band byteAdd urgent offset to sequence number field to obtain value of urgent pointerSegment may or may not contain the byte labeled as OOBDepends on number of bytes ahead of it, segment size, and current receiver window

1NFirst byte to sendlast byte to sendSocket send buffer1NOOBSocket send bufferFirst byte to sendlast byte to sendTCP Urgent PointerTCP Out-of-Band Data 3/5TCP header indicates that sender has entered urgent mode (actual byte of data referred to by urgent pointer need not be sent)IF sending TCP is stopped by flow controlUrgent notification is sent without any dataOne of the reasons why applications use TCPs urgent modeIf multiple bytes are sent out-of-bandsend (fd,abc,3,MSG_OOB);Urgent pointer points one beyond the final byte last byte is considered the out-of-band byteTCP Out-of-Band DataReceivers response to out-of-band dataTCP Checks urgent pointer to see if it refers to new out-of-band data (TCP can send multiple segments containing URG flag, but referring to same byte of data)Only first segment causes receiving process to be notified SIGURG signal delivered to socket ownerIf process blocked in a call to select (waiting for an exception condition), select returnsOnly one OOB mark, if a new OOB byte arrives before old is read, old byte is discardedTCP Out-of-Band DataReceivers response to out-of-band dataActual OOB byte can be pulled out-of-band or left inlineSO_OOBINLINE socket option (by default not set)Byte not placed in socket receive bufferByte placed into a separate one-byte out-of-band buffer for this connectionTo read from that buffer, use recv and specify MSG_OOB flagIf SO_OOBINLINE socket option is setByte left in normal socket receive bufferProcess knows when it reaches this byte of data by checking the out-of-band mark for this connectionRAW SOCKETRaw SocketsAllows you to bypass the TCP/UDP layers.

Send/receive your own packets, with your own headers.

You need to do all protocol processing at user-level.Typical UsesICMP messagesping generates ICMP echo requests and received ICMP echo replies.

Routing protocolsgated implements OSPF routing protocol.Uses IP packets with protocol ID 89 not supported by kernel.

Hacking Generating your own TCP/UDP packets with spoofed headersRaw socket creationOnly root can open a raw socket.

sockfd = socket(AF_INET, SOCK_RAW, proto)

where proto is IPPROTO_RAW, IPPROTO_ICMP etc.Raw socket outputAs usual sendto(), sendmsg() etc.

IP_HDRINCL option Specifies whether the process or the kernel builds the IP header.

/* allow process to build IP header */int on=1; setsockopt( sockfd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on))Raw socket inputNormally using recvfrom()Conditions for a packet to match raw socket

If protocol parameter was specified, only packets with that protocol value are delivered.

If bind() was called on raw socket, only packets destined to bound IP address are delivered.

If connect() was called, only packets from connected address are delivered.Which protocol types are delivered?TCP and UDP never reach raw socketsKernel IP stack handles theseLinux implementation is an exception.

All ICMP exceptICMP echo requestTimestamp requestMask request

All IGMP

All other protocols that kernel doesn't understandSuch as OSPFROUTING, MULTICASTING USING UDP SOCKETSMulticast CommunicationTransport mechanism and network layer must support multicastInternet multicast limited to UDP (not TCP)Unreliable: No acknowledgements or other error recovery schemes (perhaps at application level)Connectionless: No connection setup (although there is routing information provided to multicast-enabled routers)Datagram: Message-based multicastUDP MulticastIP supports multicastingUses only UDP, not TCPSpecial IP addresses (Class D) identify multicast groupsInternet Group Management Protocol (IGMP) to provide group routing informationMulticast-enabled routers selectively forward multicast datagramsIP TTL field limits extent of multicastRequires underlying network and adapter to support broadcast or, preferably, multicastEthernet (IEEE 802.3) supports multicast

IP Multicast: Group AddressHow to identify the receivers of a multicast datagram?How to address a datagram sent to these receivers?Each multicast datagram to carry the IP addresses of all recipients? Not scalable for large number of recipients Use address indirectionA single identifier used for a group of receivers

IP Multicast: IGMP ProtocolRFC 3376 (IGMP v3): operates between a host and its directly attached routerhost informs its attached router that an application running on the host wants to join or leave a specific multicast groupanother protocol is required to coordinate multicast routers throughout the Internet network layer multicast routing algorithmsNetwork layer multicast IGMP and multicast routing protocols IGMP enables routers to populate multicast routing tablesCarried within an IP datagram

IP Multicast: IGMP ProtocolIGMP v2 Message typesmembership query: generalSent by routers router query multicast groups joined by attached hostsmembership query: specificSent by routers query if specific multicast group joined by attached hostsmembership reportSent by host report host wants to join or is joined to given multicast groupleave group (optional)Sent by host report leaving given multicast groupIP Multicast: IGMP ProtocolJoining a groupHost sends group report when the first process joins a given groupApplication requests join, service provider (end-host) sends reportMaintaining table at the routerMulticast router periodically queries for group informationHost (service provider) replies with an IGMP report for each groupHost does not notify router when the last process leaves a group this is discovered through the lack of a report for a queryIP Multicast: Multicast RoutingMulticast routers do not maintain a list of individual members of each host groupMulticast routers do associate zero or more host group addresses with each interface

IP Multicast: Multicast RoutingMulticast router maintains table of multicast groups that are active on its networksDatagrams forwarded only to those networks with group members

IP Multicast: Multicast RoutingHow multicast routers route traffic amongst themselves to ensure delivery of group traffic?Find a tree of links that connects all of the routers that have attached hosts belonging to the multicast group Group-shared treesSource-based trees

Shared TreeSource TreesMBONE: Internet Multicast BackboneThe MBone is a virtual network on top of the Internet (section B.2)Routers that support IP multicastIP tunnels between such routers and/or subnets

Unicast versus Broadcast versus MulticastA unicast address identifies a single IP interfaceA broadcast address identifies all IP interfaces on the subnetA multicast address identifies a set of IP interfacesA multicast datagram is received only by those interfaces interested in the datagram (applications wishing to participate in the multicast group)

IPv4 Multicast Addresses 1/3Class D addresses in the range 224.0.0.0 through 239.255.255.255Low order 28 bits of class D Naddress (see appendix A) form the multicast group ID (32-bit address is the group address)Mapping of IPv4 multicast address to Ethernet addressHigh-order 24 bits of Ethernet address are always 01:00:5ENext bit always 0Low-order 23 bits are copied from low-order 23 bits of multicast group addressHigh-order 5 bits of group address are ignored in the mappingMapping not one-to-one

IPv4 Multicast Addresses 3/3Some special IPv4 multicast addresses224.0.0.0 reserved224.0.0.1 all-host group224.0.0.2 all-routers group224.0.0.1 through 224.0.0.255 reserved for routing-protocolsDatagrams destined to any of theses addresses are never forwarded by a multicast router

Sending & Receiving Multicast MessagesReceiving Multicast MessagesCreate a UDP socketBind it to a UDP port, e.g., 1234 All processes must bind to the same port in order to receive the multicast messagesJoin a multicast group addressUse recv or recvfrom to read the messages

Sending Multicast MessagesYou may use the same socket (you used for receiving) for sending multicast messages or you can use any other UDP socket (it does not have to join any multicast group)Some Multicast IssuesTime To LiveSet TTL for outgoing multicast datagrams (default is 1 local subnet)Loopback modeEnable or disable local loopback of multicast datagramsBy default loopback is enabledA copy of each multicast datagram sent by a process on the host will also be looped back and processed as a received datagram by that hostPort ReuseAllow the same multicast application to have several instances running on the same hostIn Java, Port reuse is enabled by default