You are on page 1of 70

Chapter 2: Application Layer

Silvia Giordano ICA, EPFL

2: Application Layer

Network applications are the raisons d'etre of a computer network. If we couldn't conceive of any useful applications, there wouldn't be any need to design networking protocols to support them. But over the past thirty years, many people have devised numerous ingenious and wonderful networking applications. These applications include the classic text -based applications that became popular in the 1980s, including remote access to computers, electronic mail, file transfers, newsgroups, and chat. But they also include more recently conceived multimedia applications, such as the World Wide Web, Internet telephony, video conferencing, and audio and video on demand.

Chapter goals:
q

learn about protocols by examining popular application-level protocols conceptual + implementation aspects of network application protocols
m m

client server paradigm service models

programming network applications


m

socket programming

Language used: JAVA (for C see 2000 documentation)

2: Application Layer

For JAVA programming, see JAVA Network Programming, E. R. Haro ld, OREILLY

Last week (1)


Concepts and terms:
r r

Computer Networks
m

protocol r layering and service models r network edge, core, access network r packet switching

Internet overview

Create groups of 2 people r Fill form for the group identifier r Deadlines:
r
m

For the project:

Phase 1: Design and Definition, by the 23 rd of April Phase 2: Implementation, end of the course

2: Application Layer

Last week (2)


Packet switching introduces delay per packet, but allows more users to use network! r 1 Mbit link r each user:
m m

100Kbps when active active 10% of time

r r

circuit-switching:
m

N users 1 Mbps link

10 users with 35 users, probability > 10 active less that .004

packet switching:
m

2: Application Layer

Applications and application-layer protocols


Application: communicating, distributed `C processes application transport m running in network hosts in user network data link space physical m exchange messages to implement app m e.g., email, file transfer, the Web Application-layer protocols m define messages exchanged by apps and actions taken m one piece of an app application m user services provided by lower transport network layer protocols data link physical Typical application-layer has two pieces: client and server `C
2: Application Layer

application transport network data link physical

S
5

Although network applications are diverse and have many interacting components, software is almost always at their core. The software is distributed among two or more end systems (that is, host computers). For example, with the Web there are two pieces of software that communicate with each other: the browser software in the user's host (PC, Mac, or workstation), and the Web server software in the Web server. It is important to distinguish between network applications and application-layer protocols. An application-layer protocol is only one piece (albeit, a big piece) of a network application. Let's look at a couple of examples. The Web is a network application that allows users to obtain "documents" from Web servers on demand. The Web application consists of many components, including a standard for document formats (that is, HTML), Web browsers (for example, Netscape Navigator and Microsoft Internet Explorer), Web servers (for example, Apache, Microsoft, and Netscape servers), and an application-layer protocol. The Web's application-layer protocol, HTTP (the Hypertext Transfer Protocol), defines how messages are passed between browser and Web server. Thus, HTTP is only one piece of the Web application. An application-layer protocol defines how an application's processes, running on different end systems, pass messages to each other. In particular, an application-layer protocol defines: the types of messages exchanged, for example, request messages and response messages the syntax of the various message types, such as the fields in the message and how the fields are delineated the semantics of the fields, that is, the meaning of the information in the fields rules for determining when and how a process sends messages and responds to messages A network application protocol typically has two parts or "sides," a client side and a server side. The client side in one end system communicates with the server side in another end system. For example, a Web browser implements the client side of HTTP, a nd a Web server implements the server side of HTTP.

Network applications: some P2 definitions P1


Interprocess communication

r A process is a program that

is running within a host. r Within the same host, two processes communicate with interprocess communication defined by the OS. r Processes running in different hosts communicate with an application-layer protocol r A user agent is an interface between the user and the network application.
m m m

Application Layer protocol

P3

Web:browser E-mail: mail reader streaming audio/video: media player

2: Application Layer

In the jargon of operating systems, it is not actually software pieces (that is, programs) that are communicating but in truth processes that are communicating. A process can be thought of as a program that is running within an end system. When communicating processes are running on the same end system, they communicate with each other using interprocess communication. The rules for interprocess communication are governed by the end system's operating system. But here we are not interested in how processes on the same host communicate, but instead in how processes running on different end systems (with potentially different operating systems) communicate. Processes on two different end systems communicate with each other by exchanging messages across the computer network. A sending process creates and sends messages into the network; a receiving process receives these messages and possibly responds by sending messages back.

Application-layer protocols (cont).


API: application programming interface r defines interface between application and transport layer r socket: Internet API
m

How does a process identify the other process with which it wants to communicate?
m m

two processes communicate by sending data into socket, reading data out of socket
controlled by application developer controlled by operating system

controlled by application developer controlled by operating system

process socket TCP with buffers, variables host or server

process socket TCP with buffers, variables host or server

IP address of host running other process port number - allows receiving host to determine to which local process the message should be delivered

internet

2: Application Layer

An application involves two processes in two different hosts communicating with each other over a network. (Actually, a multicast application can involve communication among more than two hosts.) The two processes communicate with each other by sending and receiving messages through their sockets. A process's socket can be thought of as the process's door: A process sends messages into, and receives message from, the network through its socket. When a process wants to send a message to another process on another host, it shoves the message out its door. The process assumes that there is a transportation infrastructure on the other side of the door that will transport the message to the door of the destination process. The figure illustrates socket communication between two processes that communicate over the Internet. (the figure assumes that the underlying transport protocol is TCP, although the UDP protocol could be used as well in the Internet.) As shown in this figure, a socket is the interface between the application layer and the transport layer within a host. It is also referred to as the API (application programmers' interface) between the application and the network, since the socket is the programming interface with which networked applications are built in the Internet. The application developer has control of everything on the application-layer side of the socket but has little control of the transport-layer side of the socket. The only control that the application developer has on the transport-layer side is (1) the choice of transport protocol and (2) perhaps the ability to fix a few transport-layer parameters such as maximum buffer and maximum segment sizes. Once the application developer chooses a transport protocol (if a choice is available), the application is built using the transport layer of the services offered by that protocol. To identify the receiving process, one must typically specify two pieces of information: (1) the name or address of the host machine, and (2) an identifier that specifies the identity of the receiving process on the destination host. The user agent is an interface between the user and the network application. For example, consider the Web. For this application, the user agent is a browser such as Netscape Navigator or Microsoft Internet Explorer. The browser allows a user to view Web pages, to navigate in the Web, to provide input to forms, to interact with Java applets, and so on. The browser also implements the client side of the HTTP protocol. Thus, when activated, the browser is a process that, along with providing an interface to the user, sends/receives messages via a socket. In Internet applications, the destination host is specified by its IP address. The IP address is a 32-bit quantity that uniquely identifies the end system (more precisely, it uniquely identifies the interface that connects that host to the Internet). Since the IP address of any end system

IP address: 32-bit identifier for host, network address of host r typically written in so-called dotteddecimal notation: 4 bytes in decimal form separated by periods r Port number: 16-bit number, ranging from 0 to 65535, network 128.1.1.1 address of process
r

From Ch4 and Ch3: few words on IP address and port number
128.178.1.1 128.178.2.1 128.178.1.2 128.178.1.4128.178.2.9 128.178.2.2 128.178.1.3 128.178.3.27

128.178.3.1

128.178.3.2

= 10000000 00000001 00000001 00000001 128 1 1 1


8

2: Application Layer

An IP address is technically associated with an interface, rather than with the host or router containing that interface When IP in the host wants to send a datagram, it will do so over this link. The boundary between the host and the physical link is called an interface. A router's job is to receive a datagram on an "incoming" link and forward the datagram on some "outgoing" link, thus a router has multiple interfaces, one for each of its links. 32 Each IP address is 32 bits long (equivalently, four bytes), and there are thus a total of 2 possible IP addresses. These addresses are typically written in so-called dotted-decimal notation, in which each byte of the address is written in its decimal form and is separated by a period ("dot") from other bytes in the address. For example, consider the IP address 193.32.216.9. The 193 is the decimal equivalent of the first eight bits of the address; the 32 is the decimal equivalent of the second eight bits of the address, and so on. Thus, the address 193.32.216.9 in binary notation is: 11000001 00100000 11011000 00001001. Each interface on every host and router in the global Internet m ust have an IP address that is globally unique.

What transport service does an app need?


Data loss
r some apps (e.g., audio) can

tolerate some loss r other apps (e.g., file transfer, telnet) require 100% reliable data transfer

Timing
r some apps (e.g., Internet

Bandwidth
r some apps (e.g., multimedia)

require minimum amount of bandwidth to be effective r other apps (elastic apps) make use of whatever bandwidth they get

telephony, interactive games) require low delay to be effective

2: Application Layer

The socket is the interface between the application process and the transport protocol. The application at the sending side sends messages through the door. At the other side of the door, the transport protocol has the responsibility of moving the messages across the network to the door at the receiving process. Many networks, including the Internet, provide more than one transport protocol. When you develop an application, you must choose one of the available transport protocols. Data Loss Some applications, such as electronic mail, file transfer, remote host access, Web document transfers, and financial applications require fully reliable data transfer, that is, no data loss. In particular, a loss of file data, or data in a financial transaction, can have devastating consequences. Other loss-tolerant applications, most notably multimedia applications such as real-time audio/video or stored audio/video, can tolerate some amount of data loss. In these latter applications, lost data might result in a small glitch in the played-out audio/video--not a crucial impairment. The effects of such loss on application quality, and actual amount of tolerable packet loss, will depend strongly on the application and the coding scheme used. Bandwidth Some applications must be able to transmit data at a certain rate in order to be effective. For example, if an Internet telephony application encodes voice at 32 Kbps, then it must be able to send data into the network and have data delivered to the receiving application at this rate. If this amount of bandwidth is not available, the application needs to encode at a different rate (and receive enough bandwidth to sustain this different coding rate) or it should give up, since receiving half of the needed bandwidth is of no use to such a bandwidth-sensitive application. Electronic mail, file transfer, remote access, and Web transfers are all elastic applications. Of course, the more bandwidth, the better. Timing The final service requirement is that of timing. Interactive real-time applications, such as Internet telephony, virtual environments, teleconferencing, and multiplayer games require tight timing constraints on data delivery in order to be effective. For example, many of these applications require that end-to-end delays be on the order of a few hundred milliseconds or less. Long delays in Internet telephony, for example, tend to result in unnatural pauses in the conversation.

Transport service requirements of common apps


Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss no loss loss-tolerant loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no no no yes, 100s msec yes, few secs yes, 100s msec yes and no

2: Application Layer

10

10

Services provided by Internet transport protocols


Transmission Control Protocol (TCP) service:
connection-oriented r reliable transport r flow control r congestion control
r

User Datagram Protocol (UDP) service:


connectionless r unreliable transport r no flow control r no congestion control
r

Both services do not provides: r timing, minimum bandwidth guarantees

2: Application Layer

11

TCP/IP networks makes available two transport protocols to applications, namely, UDP (User Datagram Protocol) and TCP (Transmission Control Protocol). When a developer creates a new application for the Internet, one of the first decisions that the developer must make is whether to use UDP or TCP. Each of these protocols offers a different service model to the invoking applications.

11

TCP Service
r r r r r

connection-oriented: setup required between client, server reliable transport between sending and receiving process flow control: sender wont overwhelm receiver congestion control: throttle sender when network overloaded does not providing: timing, minimum bandwidth guarantees

2: Application Layer

12

The TCP service model includes a connection-oriented service and a reliable data transfer service. When an application invokes TCP for its transport protocol, the application receives both of these services from TCP. Connection-oriented service: TCP has the client and server exchange transport-layer control information with each other before the application-level messages begin to flow. This socalled handshaking procedure alerts the client and server, allowing them to prepare for an onslaught of packets. After the handshaking phase, a TCP connection is said to exist between the sockets of the two processes. The connection is a full-duplex connection in that the two processes can send messages to each other over the connection at the same time. When the application is finished sending messages, it must tear down the connection. The service is referred to as a "connection-oriented" service, because the two processes are connected in a very loose manner. Reliable transport service: The communicating processes can rely on TCP to deliver all data sent without error and in the proper order. When one side of the application passes a stream of bytes into a socket, it can count on TCP to deliver the same stream of data to the receiving socket, with no missing or duplicate bytes. TCP also includes a congestion-control mechanism, a service for the general welfare of the Internet rather than for the direct benefit of the communicating processes. The TCP congestion control attempts to limit each TCP connection to its fair share of network bandwidth, sometimes throttling the transmission rate of a communication. This can have a very harmful effect on real-time audio and video applications that have a minimum required bandwidth constraint. Moreover, real-time applications are loss-tolerant and do not need a fully reliable transport service. For these reasons, developers of real-time applications usually run their applications over UDP rather than TCP. Services that TCP does not provide . First, TCP does not guarantee a minimum transmission rate. In particular, a sending process is not permitted to transmit at any rate it pleases; instead the sending rate is regulated by TCP congestion control, which may force the sender to send at a low average rate. Second, TCP does not provide any delay guarantees. When data are put into a sending socket, the data will eventually arrive at the receiving socket, but TCP guarantees absolutely no limit on how long the data may take to get there. In summary, TCP guarantees delivery of all data, but provides no guarantees on the rate of delivery or on the delays experienced.

12

UDP Service
unreliable data transfer between sending and receiving process r does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee
r

2: Application Layer

13

UDP is a no-frills, lightweight transport protocol with a minimalist service model. UDP is connectionless, so there is no handshaking before the two processes start to communicate. UDP provides an unreliable data transfer service; that is, when a process sends a message into a UDP socket, UDP provides no guarantee that the message will ever reach the receiving socket. Furthermore, messages that do arrive to the receiving socket may arrive out of order. On the other hand, UDP does not include a congestion-control mechanism, so a sending process can pump data into a UDP socket at any rate it pleases. Although all the data may not make it to the receiving socket, a large fraction of the data may arrive. Developers of real-time applications often choose to run their applications over UDP. Similar to TCP, UDP provides no guarantee on delay.

13

Internet apps: their protocols and transport protocols


Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NSF proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP

2: Application Layer

14

Most Internet applications (e.g. e-mail, remote terminal access, the Web, and file transfer) have chosen TCP primarily because TCP provides the reliable data transfer service, guaranteeing that all data will eventually get to its destination. We also see that Internet telephony typically runs over UDP. Each side of an Internet phone application needs to send data across the network at some minimum rate; this is more likely to be possible with UDP than with TCP. Also, Internet phone applications are loss-tolerant, so they do not need the reliable data transfer service provided by TCP.

14

The Web: the http protocol


http: hypertext transfer protocol
r Webs application layer
htt p re que st htt p re spo nse

protocol r client/server model m client: browser that requests, receives, displays Web objects m server: Web server sends objects in response to requests

PC running Explorer

est equ r e p ons htt esp r p htt

Server running NCSA Web server

Mac running Navigator

2: Application Layer

15

Until the 1990s the Internet was used primarily by researchers, academics, and university students to log-in to remote hosts, to transfer files from local hosts to remote hosts and vice versa, to receive and send news, and to receive and send electronic mail. The Web is the third major communication technology that has changed the way people i lve and work, after telephone and broadcast radio and television. Perhaps what appeals the most to users about the Web is that it operates on demand. Users receive what they want, when they want it. This is unlike broadcast radio and television, which force users to "tune in" when the content provider makes the content available. The Web is the Internet application that caught the general public's eye. It is dramatically changing how people interact inside and outside their work environments. It has spawned thousands of start up companies. It has elevated the Internet from just one of many data networks to essentially the one and only data network. The Hypertext Transfer Protocol (HTTP), the Web's application-layer protocol, is at the heart of the Web. HTTP is implemented in two programs: a client progra m and a server program. The client program and server program, executing on different end systems, talk to each other by exchanging HTTP messages. HTTP defines the structure of these messages and how the client and server exchange the messages. A Web page (also called a document) consists of objects. An object is simply a file --such as an HTML file, a JPEG image, a GIF image, a Java applet, an audio clip, and so on--that is addressable by a single URL. Most Web pages consist of a base HTML file and several referenced objects. For example, if a Web page contains HTML tex t and five JPEG images, then the Web page has six objects: the base HTML file plus the f ive images. The base HTML file references the other objects in the page with the objects' URLs. Each URL has two components: the host name of the server that houses the object and the object's path name. For example, the URL www.epfl.ch/someDep/picture.gif has www.epfl.ch for a host name and /someDep/picture.gif for a path name. A browser is a user agent for the Web; it displays the requested Web page and provides numerous navigational and configuration features. Web browsers also implement the client side of HTTP. Popular Web browsers include Netscape Communicator and Microsoft Internet Explorer. A Web server houses Web objects, each addressable by a URL. Web servers also implement the server side of HTTP. Popular Web servers include Apache, Microsoft Internet Information Server, and the Netscape Enterprise Server. HTTP defines how Web clients (i.e., browsers) request Web pages from Web servers and how servers transfer Web pages to clients.

15

The http protocol: more


http: TCP transport service:
r client initiates TCP

http is stateless
r server maintains no

connection (creates socket) to server, port 80 r server accepts TCP connection from client r http messages (applicationlayer protocol messages) exchanged between browser (http client) and Web server (http server) r TCP connection closed

information about past client requests

Protocols that maintain state are complex! r past history (state) must be maintained r if server/client crashes, their views of state may be inconsistent, must be reconciled
2: Application Layer

aside

16

When a user requests a Web page (for example, clicks on a hyperlink), the browser sends HTTP request messages for the objects in the page to the server. The server receives the requests and responds with HTTP response messages that contain the objects. The HTTP client first initiates a TCP connection with the server. Port number 80 is used as the default port number at which the HTTP server will be listening for HTTP clients that want to retrieve documents using HTTP. Once the connection is established, the browser and the server processes access TCP through their socket interfaces. The client sends HTTP request messages into its socket interface and receives HTTP response messages from its socket interface. Similarly, the HTTP server receives request messages from its socket interface and sends response messages into the socket interface. Once the client sends a message into its socket interface, the message is "out of the client's hands" and is "in the hands of TCP." Each HTTP request message emitted by a client process, given that TCP provides a TCP provides a reliable data transfer service, eventually arrives intact at the server; similarly, each HTTP response message emitted by the server process eventually arrives intact at the client. Here we see one of the great advantages of a layered architecture--HTTP need not worry about lost data, or the details of how TCP recovers from loss or reordering of data within the network. That is the job of TCP and the protocols in the lower layers of the protocol stack. It is important to note that the server sends requested files to clients without storing any state information about the client. If a particular client asks for the same object twice in a period of a few seconds, the server does not respond by saying that it just served the object to the client; instead, the server resends the object, as it has completely forgotten what it did earlier. Because an HTTP server maintains no information about the clients, HTTP is said to be a stateless protocol. The steps above use nonpersistent connections because each TCP connection is closed after the server sends the object--the connection does not persist for other objects. Note that each TCP connection transports exactly one request message and one response message. Thus, when a user requests a Web page that contains 6 objects, , 6 TCP connections are generated.

16

http example
Suppose user enters URL to a page with 10jpeg images
www.epfl.ch/someDep/home.index

1a. http client initiates TCP

connection to http server (process) at www.epfl.ch. Port 80 is default for http server. message (containing URL) into TCP connection socket

1b. http server at host www.epfl.ch


waiting for TCP connection at port 80. accepts connection, notifying client

2. http client sends http request

3. http server receives request

message, forms response message containing requested object (someDep/home.index), sends message into socket connection.

message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects

5. http client receives response

4. http server closes TCP

time 6. Steps 1-5 repeated for each


of 10 jpeg objects
2: Application Layer 17

The page consists of a base HTML file and 10 JPEG images, all residing on the same server. Suppose the URL for the base HTML file is www.epfl.ch/someDep/home.index. Here is what happens: 1. The HTTP client initiates a TCP connection to the server www.epfl. ch. Port number 80 is used as the default port number at which the HTTP server will be listening for HTTP clients that want to retrieve documents using HTTP. 2. The HTTP client sends a HTTP request message to the server via the socket associated with the TCP connection that was established in step 1. The request message includes the path name /someDep/home.index . (We will discuss the HTTP messages in some detail below.) 3. The HTTP server receives the request message via the socket associated with the connection that was established in step 1, retrieves the object /someDep/home.index from its storage (RAM or disk), encapsulates the object in an HTTP response message, and sends the response message to the client via the socket. 4. The HTTP server tells TCP to close the TCP connection. (But TCP doesn't actually terminate the connection until the client has received the response message intact.) 5. The HTTP client receives the response message. The TCP connection terminates. The message indicates that the encapsulated object is an HTML file. The client extracts the file from the response message, parses the HTML file, and finds references to the 10 JPEG objects. 6. The first four steps are then repeated for each of the referenced JPEG objects. As the browser receives the Web page, it displays the page to the user.

17

ftp: the file transfer protocol


FTP FTP user client interface local file system file transfer FTP server remote file system

user at host

transfer file to/from remote host r TCP transport service r client/server model m client: side that initiates transfer (either to/from remote) m server: remote host r ftp server: port 21
r
2: Application Layer 18

FTP (File Transfer Protocol) is a protocol for transferring a file from one host to another host. In a typical FTP session, the user is sitting in front of one host (the local host) and wants to transfer files to or from a remote host. In order for the user to access the remote account, the user must provide a user identification and a password. After providing this authorization information, the user can transfer files from the local file system to the remote file system and vice versa. As shown in the figure, the user interacts with FTP through an FTP user agent. The user first provides the hostname of the remote host, causing the FTP client process in the local host to establish a TCP connection with the FTP server process in the remote host. The user then provides the user identification and password, which get sent over the TCP connection as part of FTP commands. Once the server has authorized the user, the user copies one or more files stored in the local file system into the remote file system (or vice versa).

18

Electronic Mail
r r r

outgoing message queue user mailbox user agent mail server user agent mail server user agent user agent

TCP transport protocol port 25 client/server model

SMTP SMTP
mail server

r Three major

components:
m user

agents m mail servers m simple mail transfer protocol: smtp

SMTP
user agent

user agent

2: Application Layer

19

Just like snail-mail, e-mail is asynchronous people send and read messages when it is convenient for tem, without having to coordinate with other people schedules. It is form by three major components: q user agents (mail readers), that are used for composing, editing, reading mail messages, e.g. Eudora, Outlook, elm, Netscape Messenger q mail servers, that works as q mailboxcontaining incoming messages (yet to be read) for user q message queue of outgoing (to be sent) mail messages q transfer protocol (simple mail transfer protocol: SMTP) that uses tcp to reliably transfer email msg from client to server, port 25. It is a direct transfer between sending server to receiving server in three phases q handshaking (greeting) q transfer of messages q Closure

19

Socket programming
Goal: learn how to build client/server application that communicate using sockets Socket API
r introduced in BSD4.1 UNIX, 1981 r explicitly created, used, released by r client/server paradigm
m m

socket
a host-local, applicationcreated/owned, OS-controlled interface (a door) into which application process can both send and receive messages to/from another (remote or local) application process

apps

implementation proprietary

r two types of transport service via

socket API: m unreliable datagram m reliable, byte stream-oriented

2: Application Layer

20

Data are transmitted across the Internet in packets of finite size called datagrams. Each datagram contains a header and a payload. It is offen necessary to split datagrams into multiple packets and then reassemble it at destination. Packets can follow different path into the network, can get corrupted, get loss, get delayed, etc.. Sockets are an innovation of Berkeley UNIX (BSD4.1).They allow the programmer to treat network connections as streams that bytes can be written o nto and read from. Socket are an abstraction that shields the programmer from low-level details of the network, like media types, packet sizes, packet loss and retransmission, network addresses, and more. The core of a network application consists of a pair of programs--a client program and a server program. When these two programs are executed, a client and server process are created, and these two processes communicate with each other by reading from and writing to sockets. When creating a network application, the developer's main task is to write the code for both the client a nd server programs. There are two sorts of client/server applications. One sort is a client/server application that is an implementation of a protocol standard defined in an RFC. For such an implementation, the client and server programs must conform to the rules dictated by the RFC. If one developer writes code for the client program and an independent developer writes code for the server program, and both developers carefully follow the rules of the RFC, then the two programs will be able to interoperate. Indeed, most of today's network applications involve communication between client and server programs that have been created by independent developers. (For example, a Netscape browser communicating with an Apache Web server, or an FTP client on a PC uploading a file to a Unix FTP server.) When a client or server program implements a protocol defined in an RFC, it should use the port number associated with the protocol. The other sort of client/server application is a proprietary client/server application. In this case the client and server programs do not necessarily conform to any existing RFC. A single developer creates both the client and server programs, and has complete control over what goes in the code. But because the code does not implement a public-domain protocol, other independent developers will not be able to write code that interoperates with the application. When developing a proprietary application, the developer must be careful not to use one of the well-known port numbers defined in the RFCs. TCP is connection-oriented and provides a reliable byte-stream channel through which data flows between two end systems. UDP is connectionless and sends independent

20

Socket programming with TCP


Client must contact server
r server process must first r When client creates socket:

be running r server must have created socket (door) that welcomes clients contact Client contacts server by: r creating client-local TCP socket r specifying IP address, port number of server process

client TCP establishes connection to server TCP

r When contacted by client,

server TCP creates new socket for server process to communicate with client m allows server to talk with multiple clients

application viewpoint TCP provides reliable, in-order transfer of bytes (pipe) between client and server
2: Application Layer 21

The client has the job of initiating contact with the server. In order for the server to be able to react to the client's initial contact, the server has to be ready. This implies two things. First, the server program cannot be dormant; it must be running as a process before the client attempts to initiate contact. Second, the server program must have some sort of door (that is, socket) that welcomes some initial contact from a client running on an arbitrary machine. Using our house/door analogy for a process/socket, we will sometimes refer to the client's initial contact as "knocking on the door." With the server process running, the client process can initiate a TCP connection to the server. This is done in the client program by creating a socket object. When the client creates its socket object, it specifies the address of the server process, namely, the IP address of the server and the port number of the process. Upon creation of the socket object, TCP in the client initiates a three-way handshake and establishes a TCP connection with the server. The three-way handshake is completely transparent to the client and server programs. During the three-way handshake, the client process knocks on the welcoming door of the server process. When the server "hears" the knocking, it creates a new door (that is, a new socket) that is dedicated to that particular client. In our example below, the welcoming door is a ServerSocket object that we call the welcomeSocket. When a client knocks on this door, the program invokes welcomeSocket's accept() method, which creates a new door for the client. At the end of the handshaking phase, a TCP connection exists between the client's socket and the server's new socket. Henceforth, we refer to the new socket as the server's connection socket.

21

Input and Output streams

2: Application Layer

22

From the application's perspective, the TCP connection is a direct virtual pipe between the client's socket and the server's connection socket. The client process can send arbitrary bytes into its socket; TCP guarantees that the server process will receive (through the connection socket) each byte in the order sent. Furthermore, just as people can go in and out the same door, the client process can also receive bytes from its socket and the server process can also send bytes into its connection socket. Because sockets play a central role in client/server applications, client/server application development is also referred to as socket programming. Before providing our example client/server application, it is useful to discuss the notion of a stream. A stream is a sequence of characters that flow into or out of a process. Each stream is either an input stream for the process or an output stream for t he process. If the stream is an input stream, then it is attached to some input source for the process, such as standard input (the keyboard) or a socket into which data flow from the Internet. If the stream is an output stream, then it is attached to some output source for the process, such as standard output (the monitor) or a socket out of which data flow into the Internet.

22

Socket programming with TCP


Example client-server app:
r client reads line from

standard input (inFromUser stream) , sends to server via socket (outToServer stream) r server reads line from socket r server converts line to uppercase, sends back to client r client reads, prints modified line from socket (inFromServer stream)

Input stream: sequence of bytes into process Output stream: sequence of bytes out of process
outToServer

process
inFromUser

client socket
2: Application Layer 23

We will use the following simple client/server application to demonstrate socket programming for both TCP and UDP: A client reads a line from its standard input (keyboard) and sends the line out its socket to the server. The server reads a line from its connection socket. The server converts the line to uppercase. The server sends the modified line out its connection socket to the client. The client reads the modified line from its socket and prints the line on its standard output (monitor). We use Java code for several reasons. First, the applications are more neatly and cleanly written in Java; with Java there are fewer lines of code, and each line can be explained to the novice programmer without much difficulty. Second, client/server programming in Java is becoming increasingly popular, and may even become the norm in upcoming years. Java is platform-independent, it has exception mechanisms for robust handling of common problems that occur during I/O and networking operations, and its threading facilities provide a way to easily implement powerful servers. Thirdly, you must be very familiar with Java. You should be able to follow the code and to easily solve the exercises. Finally, the project we propose as part of this course, given that involves the WEB and HTTP, it comes more natural with JAVA. For students who are interested in client/server programming in C, a good refence is the course of 2000, from Prof. Le Boudec.

inFromServer

23

Client/server socket interaction: TCP


Server
(running on hostid)

Client

create socket, port=x, for incoming request: welcomeSocket = ServerSocket() wait for incoming connection request connection connectionSocket = welcomeSocket.accept() read request from connectionSocket write reply to connectionSocket close connectionSocket

TCP

setup

create socket, connect to hostid, port=x clientSocket = Socket() send request using clientSocket

read reply from clientSocket close clientSocket 2: Application Layer 24

Let us begin with the case of a client and server communicating over a connection- oriented (TCP) transport service. In the figure, the main socket-related activity of the client and server are shown. Normally, a TCP server runs on a specific computer and has a socket that is bound to a specific port number. The server just waits, listening to the socket for a TCP client to make a connection request. On the client-side: The client knows the hostname of the machine on which the server is running and the port number to which the server is connected. To make a connection request, the client tries to rendezvous with the server on the server's machine and port. If everything goes well, the server accepts the connection. Upon acceptance, the server gets a new socket bound to a different port. It needs a new socket (and consequently a different port number) so that it can continue to listen to the original socket for connection requests while tending to the needs of the connected client. On the client side, if the connection is accepted, a socket is successfully created and the client can use the socket to communicate with the server. Note that the socket on the client side is not bound to the port number used to rendezvous with the server. Rather, the client is assigned a port number local to the machine on which the client is running. The TCP client and server can now communicate by writing to or reading from their sockets.

24

JAVA TCP Sockets


Socket operations
r r r r r r r

Connect to a remote machine Send data Receive data Close a connection Bind to a port Listen for incoming data Accept connections from a remote machine on the bound port

Socket class

ServerSocket class
2: Application Layer

25

The java.net package in the Java platform provides a class, Socket, that implements one side of a two-way connection between your Java program and another program on the network. The Socket class sits on top of a platform-dependent implementation, hiding the details of any particular system from your Java program. By using the java.net.Socket class instead of relying on native code, your Java programs can communicate over the network in a platformindependent fashion. Javas Socket class, has methods for connecting to a remote machine, sending and receiving data, closing a connection. The meaning of the data sent and received depends on the Internet protocol. There will normally be some agreed upon handshaking fo llowed by the transmission of data from one to another. Additionally, java.net includes the ServerSocket class, which implements a socket that servers can use to listen for and accept connections to clients.

25

InetAddress object
r r r r r r

Each host has atleast one IP address Java uses 32-bit addresses format, but it is designed for supporting 128-bit addresses InetAddress represents an IP address Two fields: hostName (String) and address (int) No public constructors Fields not public, accessed via three static methods:
m m m

public static InetAddress InetAddress.getByName (String hostname) public static InetAddress InetAddress.getAllByName (String hostname) public static InetAddress InetAddress.getLocalHost ()

2: Application Layer

26

Each host in the Internet is identified with at least one IP address or Internet address. This is a 32-bit number in the current IPv4, and will move to 128-bit number with IPv6. Note that the object oriented model of Java will keep this change quite transparent to the users. The java.net.InetAddress class represents an Internet address. I contains two fields: hostName (a String), and address (an int). The hostName contains the name of the host (e.g. lrcsun6.epfl.ch). Address contains a 32-bit IP address. These fields are not public, so they cannot be accessed directly. There are three methods that allows users to initialize an InetAddress object: public static InetAddress InetAddress.getByName (String hostname ) This static method takes an hostname or an IP address in the four unsigned bytes format: InetAddress InetAddress.getByName (lrcsun6.epfl.ch) InetAddress InetAddress.getByName (123.123.123.123) This method throws an UnknownHostException if the host cannot be found. public static InetAddress[] InetAddress.getAllByName (String hostname) This static method takes an hostname and returns all the InetAddresses corresponding to the given hostname: InetAddress InetAddress.getByName (lrcsun6.epfl.ch) If lrcsun6.epfl.ch has more than one IP interface, InetAddress.getAllByName inizialize an InetAddress object for each of them. If there is only one, the result is the same as InetAddress.getByName. Also this method throws an UnknownHostException if the host cannot be found. public static InetAddress InetAddress.getLocalHost () This static method returns the InetAddress of the host on which it is running. InetAddress InetAddress. getLocalHost () Like previous methods, this method throws an UnknownHostException if the local host cannot be found.

26

Socket Class
r Used for both client and

java.lang.Object | +--java.net.Socket

server r New socket is created using a Socket() constructor r 4 constructors + 2 protected r Connect with creation

public class Socket extends Object


controlled by application developer controlled by operating system

controlled by application developer controlled by operating system

process socket TCP with buffers, variables

process socket TCP with buffers, variables

internet

host or server

host or server
2: Application Layer 27

The public class Socket (extends Object) implements sockets. The actual work of the socket is performed by an instance of the SocketImpl class. An application, by changing the socket factory that creates the socket implementation, can configure itself to create sockets appropriate to the local firewall. There are four public Socket constructor that let you specify the host (InetAddress or String) and the port (int value between 0 and 65,535) you want to connect to. Two of the constructor specifies also the local address and port from which the data will be sent (useful for host with multiple interfaces). In Java 1.1 there exists also two protected constructor that can be useful if you want to implement a new type of Socket by creating a subclass of Socket. CONSTRUCTORS Socket(InetAddress address, int port) Creates a stream socket and connects it to the specified port number at the specified IP address. Socket(String host, int port) Creates a stream socket and connects it to the specified port number on the named host. Socket(String host, int port, InetAddress localAddr,int localPort ) Creates a socket and connects it to the specified remote host on the specified remote port. Socket(InetAddress address, int port, InetAddress localAddr,int localPort) Creates a socket and connects it to the specified remote address on the specified remote port. PROTECTED Socket(SocketImpl impl) Creates an unconnected Socket with a user-specified SocketImpl. Socket() Creates an unconnected socket, with the system-default type of SocketImpl.

27

Constructors

remote host and port you want to connect to

Internet address of remote host r public Socket(String host , int port) throws

UnknownHostException, IOException

r public Socket(InetAddress address, int port) DNS dont know throws IOException the host or is not working r public Socket(String host, int port, local host and port r public Socket(InetAddress address, int port,

InetAddress localAddr, int localPort) throws IOException InetAddress localAddr, int localPort) throws IOException

2: Application Layer

28

Socket public Socket(String host ,int port) throws UnknownHostException, IOException Creates a stream socket and connects it to the specified port number on the named host. If the application has specified a server socket factory, that factory's createSocketImpl method is called to create the actual socket implementation. Otherwise a "plain" socket is created. If there is a security manager, its checkConnect method is called with the host address and port as its arguments. This could result in a SecurityException. Throws: IOException - if an I/O error occurs when creating the socket; SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation. ************************************************************************** Socket public Socket(InetAddress address,int port) throws IOException Creates a stream socket and connects it to the specified port number at the specified IP address. If the application has specified a socket factory, that factory's createSocketImpl method is called to create the actual socket implementation. Otherwise a "plain" socket is created. If there is a security manager, its checkConnect method is called with the host address and port as its arguments. This could result in a SecurityException. Throws: IOException - if an I/O error occurs when creating the socket; SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation. **************************************************************************** Socket public Socket(String host, int port, InetAddress localAddr, int localPort) throws IOException Creates a socket and connects it to the specified remote host on the specified remote port. The Socket will also bind() to the local address and port supplied. If there is a security manager, its checkConnect method is called with the host address and port as its arguments. This could result in a SecurityException. Throws: SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation. **************************************************************************** Socket public Socket(InetAddress address,int port ,InetAddress localAddr,int localPort) throws IOException Creates a socket and connects it to the specified remote address on the specified remote port. The Socket will also bind() to the local address and port supplied. If there is a security manager, its checkConnect method is called with the host address and port as its arguments. This could result in a SecurityException. Throws: SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation.

28

Example1: public Socket(String host , int port)


throws UnknownHostException, IOException
import java.io.* import java.net.*;

remote port

public class Port80 { public static void main(String[] args) { Socket theSocket; remote host try { theSocket = new Socket(icawww.epfl.ch", 80); } catch (UnknownHostException e) { System.err.println("Don't know about ICAWWW."); System.exit(1); } catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } } 2: Application Layer }

29

This example illustrates how a program can establish a TCP connection to a server program that runs on the port 80 (Web server) on the icawww.epfl.ch host. In this constructor, the host argument is just a hostname expressed as a string icawww.epfl.ch" . There are two possible exceptions:
catch (UnknownHostException e) { System.err.println("Don't know about ICAWWW."); System.exit(1); } In this case the host running the server is unknown (e.g. Mistyping error) or the DNS is not working thus the hostname cannot be converted to any hostaddress. The constructor throws a UnknownHostException. catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } In this case the host running the server can be reached, but for some other reason it is not possible to open the connection. The constructor throws a IOException .

29

Example2: public Socket(InetAddress


int port) throws IOException
import java.io.*; import java.net.*;

host ,

public class Port80New { remote port public static void main(String[] args) { String host = icawww.epfl.ch; Internet address Socket theSocket; of remote host try { InetAddress theAddress = InetAddress.getByName(host); theSocket = new Socket( theAddress, 80); } catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } } }
2: Application Layer 30

This example illustrates again how a program can establish a TCP connection to a server program that runs on the port 80 (Web server) on the icawww.epfl.ch host. In this constructor, the host argument is specified as an InetAddress object, that is the Internet address of the specified host icawww.epfl.ch" . There is just one possible exception, because, if the host is unknown, it will find out when creating the InetAddress object:
catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } In this case the host running the server can be reached, but for some other reason it is not possible to open the connection. The constructor throws a IOException .

30

Example3: public Socket(String host, int port,


InetAddress localAddr, int localPort) throws IOException
import java.io.* import java.net.*;

remote host

public class Port80New2 { port public static void main(String[] args) remote { local port String host = "icawww.epfl.ch"; String myHost = "lrcsun6.epfl.ch"; Internet address Socket theSocket; of local interface try { InetAddress myAddress =InetAddress.getByName(myHost); theSocket = new Socket(host, 80, myAddress, 1025); } catch (UnknownHostException e) { System.err.println("Don't know about ICAWWW."); System.exit(1); } catch (IOException e) { System.err.println("Couldn't get I/O for the connection " + "to ICAWWW or dont know about ICAWWW " + "or cannotbind the local network interface."); System.exit(1); } } 2: Application Layer 31 } This example is still an example of how a program can establish a TCP connection to a server program that runs on the port 80 (Web server) on the icawww.epfl.ch host, but in this case it connects from the network interface specified by the InetAddress object, and from the local port specified by the second int. In this constructor, the remote host argument is specified as the String object icawww.epfl.ch" ; the local host argument is specified as an InetAddress object, that is the Internet address of the local network interface, which can be physical (a different ethernet card) or virtual (a multihomed host). There is just one possible exception, because, if the host is unknown, it will find out when creating the InetAddress object:
catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } In this case, for some reason it is not possible to open the connection. The constructor throws a IOException . Furthermore, the IOException can represent two different types of exceptions, which are not specified in the throws clause of this method: the host running the server cannot be reached (it corresponds to a UnknownHostException)
The host is unable to bind to the network interface specified in localAddr (it correspond to a BindException)

31

Example4: public Socket(InetAddress address, int port,


InetAddress localAddr, int localPort) throws, IOException
import java.io.* import java.net.*;

local port public static void main(String[] args) { remote port String host = "icawww.epfl.ch"; String myHost = "lrcsun6.epfl.ch"; Internet address Socket theSocket; of local interface try { InetAddress theAddress = InetAddress.getByName(host); InetAddress myAddress = InetAddress.getByName(myHost); theSocket = new Socket(theAddress, 80, myAddress, 1025); } catch (UnknownHostException e) { System.err.println("Don't know about ICAWWW."); System.exit(1); } catch (IOException e) { System.err.println("Couldn't get I/O for the connection to" + "ICAWWW or cannot bind the local network interface."); System.exit(1); } } 2: Application Layer 32 }
This example shows how to use the forth constructor for writing a program that can establish a TCP connection to a server program that runs on the port 80 (Web server) on the icawww.epfl.ch host. In this constructor, both the host argument and the local network interface are specified as an InetAddress objects, that is the Internet address of the specified host icawww.epfl.ch" . As with the third constructor, the Internet address of the local network interface, can be physical (a different ethernet card) or virtual (a multihomed host). There is just one possible exception, because, if the host is unknown, it will find out when creating the InetAddress object:
catch (IOException e) { System.err.println("Couldn't get I/O for " + "the connection to ICAWWW."); System.exit(1); } In this case, but for some other reason it is not possible to open the connection. The constructor throws a IOException . Both the host running the server and the local network interface can be reached, as specified by addresses, but the host can be unable to bind to the network interface specified in localAddr (it correspond to a BindException). As in the previous case, this is not not specified in the throws clause of this method that throws a IOException.

Internet address of remote interface public class Port80New3 {

32

Most useful methods


r void close() sockets have no public fields

r InetAddress getInetAddress() r InetAddress getLocalAddress() r int getPort() r int getLocalPort() r InputStream getInputStream() r OutputStream getOutputStream() getting info about socket
2: Application Layer 33

public void close() throws IOException Closes this socket. Throws an IOException - if an I/O error occurs when closing this socket. public InetAddress getInetAddress() Returns the IP address of the remote host to which the socket is connected. public InputStream getInputStream() throws IOException Returns an input stream for reading bytes from this socket. Throws an IOException - if an I/O error occurs when creating the input stream. public InetAddress getLocalAddress() Gets the local address to which the socket is bound. public int getLocalPort() Returns the port number of the local host to which this socket is bound. public OutputStream getOutputStream() throws IOException Returns an output stream for writing bytes to this socket. Throws an IOException - if an I/O error occurs when creating the output stream. public int getPort() Returns the port number of the remote host to which this socket is connected.

33

Getting information about a Socket


r

InetAddress getInetAddress()
try {

int getPort()
try {

Socket theSocket = new Socket(icawww.epfl.ch", 80); InetAddress host = theSocket.getInetAddress(), System.out.println(host); } catch (UnknownHostException e) { System.err.println(e); } catch (IOException e) { System.err.println(e); } Socket theSocket = new Socket(icawww.epfl.ch", 80); int port = theSocket.getPort(), System.out.println(port); } catch (UnknownHostException e) { System.err.println(e); } catch (IOException e) { System.err.println(e); 2: Application Layer }

34

To a programmer, Socket objects appear to have several private field that are accessible through various get methods. Actually, sockets have only one field, a SocketImpl; the fields that appear to belong to the socket objects actually belong to the SocketImpl. This way, the implementation of a socket can be changed without interacting with the program, because the SocketImpl is almost completely transparent. Get an address There are two methods to get what host a socket is connected to and which network interface a socket is bound to, respectively: InetAddress getInetAddress() InetAddress getLocalAddress() Get a port There are two ends of a connection. Consequently there are two m ethods to find the port number to which a socket is (will be) connected on the remote host and for the local end of the connection. Namely: int getPort() int getLocalPort() Note that, unlike the remote port, that MUST be the port on which already run the server, the local port is usually chosen by the system at runtime from the available unused ports (> 1025). This way, many different clients on the same system can access the same service at the same time.

34

Getting information about a Socket


InputStream getInputStream() r OutputStream getOutputStream()
r try { Socket echoSocket = new Socket(lrcsuns.epfl.ch", 7); PrintWriter out = new PrintWriter(echoSocket.getOutputStream(), true); BufferedReader in = new BufferedReader(new InputStreamReader( echoSocket.getInputStream())); BufferedReader stdIn = new BufferedReader( new InputStreamReader(System.in)); String userInput; while ((userInput = stdIn.readLine()) != null) { out.println(userInput); System.out.println("echo: " + in.readLine()); }
2: Application Layer 35

Read data from and write data to a socket The InputStream and the OutputStream are used to read and write data to a socket. For example, in the Internet echo protocol, defined in RFC862, the client opens a socket to port 7 on the echo server, sends data (i.e. write on the outputs tream) and the server send the data back (i.e. The client can read it on the inputstream). Example % telnet localhost 7 Trying 127.0.0.1... Connected to localhost. Escape character is ^]. This is my first test J This is my first test J This my second test J This my second test J Im the best! Im the best! . % To implement a simple echo client we can use the getInputStream() and getOutputStream(). The program closes when the users input a blank line. The sockets input stream is returned by getInputStream(), and chained to a BufferedReade. The socket's output stream is returned by getOutputStream() and then the program opens a PrintWriter on ot. The program uses readers and writers so that it can write Unicode characters over the socket.

35

Closing a Socket
import java.io.* import java.net.*; public class Port80AndClose { public static void main(String[] args) { Socket theSocket; try { theSocket = new Socket(icawww.epfl.ch", 80); } catch (UnknownHostException e) { System.err.println("Don't know about ICAWWW."); System.exit(1); } catch (IOException e) { System.err.println(e); } theSocket.close(); } }
2: Application Layer 36

It is true that sockets are closed automatically when the program ends or when they are garbage collected. However, it is a bad pratice to assume that the system will close the socket for you. Expecially because it could happen that a socket that is not properly closed remains hanged on its port and the associated memory space keeps on going to be unavailable. The method close() is used to disconnect a socket. Once the socket has been closed, its InetAddress, portnumber, local address, and local port number are still accessible as explained before. On the contrary, attempting to read data on the InputStream or write data on the OutputStream throws an IOException.

36

Other methods (1)


r int getReceiveBufferSize() r int getSendBufferSize() r int getSoLinger() r int getSoTimeout() r boolean getTcpNoDelay() r void setReceiveBufferSize(int size)

getting socket options


2: Application Layer 37

public int getReceiveBufferSize() throws SocketException Get value of the SO_RCVBUF option for this socket, that is the buffer size used by the platform for input on the this Socket. public int getSendBufferSize() throws SocketException Get value of the SO_SNDBUF option for this socket, that is the buffer size used by the platform for output on the this Socket. public int getSoLinger() throws SocketException Returns setting for SO_LINGER. -1 returns implies that the option is disabled. public int getSoTimeout() throws SocketException Returns setting for SO_TIMEOUT. 0 returns implies that the option is disabled (i.e., timeout of infinity). public boolean getTcpNoDelay() throws SocketException Tests if TCP_NODELAY is enabled. public void setReceiveBufferSize(int size) throws SocketException Sets the SO_RCVBUF option to the specified value for this DatagramSocket. The SO_RCVBUF option is used by the platform's networking code as a hint for the size to use to allocate set the underlying network I/O buffers. Increasing buffer size can increase the performance of network I/O for high-volume connection, while decreasing it can help reduce the backlog of incoming data. For UDP, this sets the maximum size of a packet that may be sent on this socket. Because SO_RCVBUF is a hint, applications that want to verify what size the buffers were set to should call IllegalArgumentException - if the value is 0 or is negative.

37

Other methods (2)


r void setSendBufferSize(int size) r static void setSocketImplFactory(SocketImplFactory fac) r void setSoLinger(boolean on, int linger) r void setSoTimeout(int timeout) r void setTcpNoDelay(boolean on) r String toString() setting socket options
2: Application Layer 38

public void setSendBufferSize(int size) throws SocketException Sets the SO_SNDBUF option to the specified value for this DatagramSocket. The SO_SNDBUF option is used by the platform's networking code as a hint for the size to use to allocate set the underlying network I/O buffers. Increasing buffer size can increase the performance of network I/O for high-volume connection, while decreasing it can help reduce the backlog of incoming data. For UDP, this sets the maximum size of a packet that may be sent on this socket. Because SO_SNDBUF is a hint, applications that want to verify what size the buffers were set to should call IllegalArgumentException - if the value is 0 or is negative. public static void setSocketImplFactory(SocketImplFactory fac) throws IOException Sets the client socket implementation factory for the application. The factory can be specified only once. When an application creates a new client socket, the socket implementation factory's createSocketImpl method is called to create the actual socket implementation. If there is a security manager, this method first calls the security manager's checkSetFactory method to ensure the operation is allowed. This could result in a SecurityException. public void setSoLinger(boolean on, int linger) throws SocketException Enable/disable SO_LINGER with the specified linger time in seconds. If the specified value exceeds 65,535 it will be reduced to 65,535. public void setSoTimeout(int timeout)throws SocketException Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a nonzero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.io.InterruptedIOException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout. public void setTcpNoDelay(boolean on) throws SocketException Enable/disable TCP_NODELAY (disable/enable Nagle's algorithm). public String toString() Overrides toString in class Object. Returns a string representation of this socket.

38

ServerSocket Class
Used for server New socket is created using a ServerSocket() constructor r 3 constructors
r r java.lang.Object | +--java.net.ServerSocket

public class ServerSocket extends Object

controlled by application developer controlled by operating system

process socket TCP with buffers, variables

process socket TCP with buffers, variables

controlled by application developer controlled by operating system

internet

host or server

host or server
2: Application Layer 39

The class ServerSocket (extends Object) implements server sockets. A server socket is like a person who sits by the phone, and waits for incoming calls: He does not know when a call will come and who will call. A server waits for requests to come in over the network: it does not know from which host the request will come and when. Once contacted, it performs some operation based on that request, and then possibly returns a result to the requester. The actual work of the server socket is performed by an instance of the SocketImpl class. An application can change the socket factory that creates the socket implementation to configure itself to create sockets appropriate to the local firewall. There are three ServerSocket constructor that allows to ceates a server socket on a specified port (int value between 0 and 65,535). Two of the constructors also bind the server to the specified local port number. One constructor uses also the tocal IP address to bind the server to. CONSTRUCTORS ServerSocket(int port) Creates a server socket on a specified port. ServerSocket(int port, int backlog) Creates a server socket and binds it to the specified local port number. ServerSocket(int port, int backlog, InetAddress bindAddr) Create a server with the specified port, listen backlog, and local IP address to bind to.

39

Constructors
r ServerSocket(int port) throws IOException r ServerSocket(int port, int backlog) throws

IOException

r ServerSocket(int port, int backlog,

InetAddress bindAddr) throws IOException

2: Application Layer

40

public ServerSocket(int port) throws IOException Creates a server socket on a specified port. A port of 0 creates a socket on any free port. The maximum queue length for incoming connection indications (a request to connect) is set to 50. If a connection indication arrives when the queue is full, the connection is refused. If the application has specified a server socket factory, that factory's createSocketImpl method is called to create the actual socket implementation. Otherwise a "plain" socket is created. If there is a security manager, its checkListen method is called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws :IOException - if an I/O error occurs when opening the socket; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public ServerSocket(int port, int backlog) throws IOException Creates a server socket and binds it to the specified local port number. A port number of creates a socket on any free port. The maximum queue length for incoming connection indications (a request to connect) is set to the backlog parameter. If a connection indication arrives when the queue is full, the connection is refused. If the application has specified a server socket factory, that factory's createSocketImpl method is called to create the actual socket implementation. Otherwise a "plain" socket is created. If there is a security manager, its checkListen method is called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws: IOException - if an I/O error occurs when opening the socket; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException Create a server with the specified port, listen backlog, and local IP address to bind to. The bindAddr argument can be used on a multi-homed host for a ServerSocket that will only accept connect requests to one of its addresses. If bindAddr is null, it will default accepting connections on any/all local addresses. The port must be between 0 and 65535, inclusive. If there is a security manager, this method calls its checkListen method with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws: SecurityException - if a security manager exists and its checkListen method doesn't allow the operation.

40

Methods
r Socket accept() r void close()

r InetAddress getInetAddress()

r int getLocalPort() r protected void implAccept(Socket s) r static void

setSocketFactory(SocketImplFactory fac) r int getSoTimeout() r Void setSoTimeout(int timeout) r String toString()


2: Application Layer 41

public Socket accept() throws IOException Listens for a connection to be made to this socket and accepts it. The method blocks until a connection is made. A new Socket s is created and, if there is a security manager, t he security manager's checkAccept method is called with s.getInetAddress().getHostAddress() and s.getPort() as its arguments to ensure the operation is allowed. This could result in a SecurityException. Throws : IOException - if an I/O error occurs when waiting for a connection; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public void close() throws IOException Closes this socket. Throws an IOException - if an I/O error occurs when closing this socket. public InetAddress getInetAddress() Returns the IP address to which this socket is connected, or null if the socket is not yet connected.. public int getLocalPort() Returns the port number to which this socket is listening. protected final void implAccept(Socket s) throws IOException Subclasses of ServerSocket use this method to override accept() to return their own subclass of socket. So a FooServerSocket will typically hand this method an empty FooSocket(). On return from implAccept the FooSocket will be connected to a client. public static void setSocketFactory(SocketImplFactory fac) throws IOException Sets the server socket implementation factory for the application. The factory can be specified only once. When an application creates a new server socket, the socket implementation factory's createSocketImpl method is called to create the actual socket implementation. If there is a security manager, this method first calls the security manager's checkSetFactory method to ensure the operation is allowed. This could result in a SecurityException. Throws : IOException - if an I/O error occurs when setting the socket factory; SocketException - if the factory has already been defined; SecurityException - if a security

41

Last Week
r

application elements:
m m m m

r Socket

programming with TCP

user agent process application-layer protocol API

Server process must first be running and created welcome socket Client creates client-local TCP socket specifying IP address, port number of server process at welcome socket Client TCP connects to server TCP Server creates new TCP socket for server process to communicate with client (multithreads) TCP provides reliable, in-order transfer of bytes between client and server Client and Server processes uses streams for input and output data Java has 2 classes for TCP sockets: Socket and ServerSocket
2: Application Layer 42

client-server paradigm r Internet transport service model


r
m m

connection-oriented, reliable: TCP unreliable, datagrams: UDP

42

Last Week: Socket programming example TCP = write on pipes


Example client-server app:
r client reads line from

standard input (inFromUser stream) , sends to server via socket (outToServer stream) r server reads line from socket r server converts line to uppercase, sends back to client r client reads, prints modified line from socket (inFromServer stream)

Input stream: sequence of bytes into process Output stream: sequence of bytes out of process
outToServer

process
inFromUser

client socket
2: Application Layer 43

We will use the following simple client/server application to demonstrate socket programming for both TCP and UDP: A client reads a line from its standard input (keyboard) and sends the line out its socket to the server. The server reads a line from its connection socket. The server converts the line to uppercase. The server sends the modified line out its connection socket to the client. The client reads the modified line from its socket and prints the line on its standard output (monitor). We use Java code for several reasons. First, the applications are more neatly and cleanly written in Java; with Java there are fewer lines of code, and each line can be explained to the novice programmer without much difficulty. Second, client/server programming in Java is becoming increasingly popular, and may even become the norm in upcoming years. Java is platform-independent, it has exception mechanisms for robust handling of common problems that occur during I/O and networking operations, and its threading facilities provide a way to easily implement powerful servers. Thirdly, you must be very familiar with Java. You should be able to follow the code and to easily solve the exercises. Finally, the project we propose as part of this course, given that involves the WEB and HTTP, it comes more natural with JAVA. For students who are interested in client/server programming in C, a good refence is the course of 2000, from Prof. Le Boudec.

inFromServer

43

Client/server socket interaction: TCP


Server
(running on hostid)
create socket, port=x, for incoming request: welcomeSocket = ServerSocket()

aaaa

Client aaaa client socket on port 2222 default local port AAAA e.g. 2222

server socket TCP wait for incoming for this client on connection request connection setup connectionSocket default local port = welcomeSocket.accept() e.g. 3333 PIPE read stream from connectionSocket ESTABLISHED
write uppercase stream to connectionSocket

port x 3333 AAAA

create socket, connect to hostid, port=x clientSocket = Socket() send stream using clientSocket

read uppercase stream from clientSocket close clientSocket 2: Application Layer 44

close connectionSocket

Let us begin with the case of a client and server communicating over a connection- oriented (TCP) transport service. In the figure, the main socket-related activity of the client and server are shown. Normally, a TCP server runs on a specific computer and has a socket that is bound to a specific port number. The server just waits, listening to the socket for a TCP client to make a connection request. On the client-side: The client knows the hostname of the machine on which the server is running and the port number to which the server is connected. To make a connection request, the client tries to rendezvous with the server on the server's machine and port. If everything goes well, the server accepts the connection. Upon acceptance, the server gets a new socket bound to a different port. It needs a new socket (and consequently a different port number) so that it can continue to listen to the original socket for connection requests while tending to the needs of the connected client. On the client side, if the connection is accepted, a socket is successfully created and the client can use the socket to communicate with the server. Note that the socket on the client side is not bound to the port number used to rendezvous with the server. Rather, the client is assigned a port number local to the machine on which the client is running. The TCP client and server can now communicate by writing to or reading from their sockets.

44

Example: Java client (TCP)

2: Application Layer

45

The socket is called clientSocket . The stream inFromUser is an input stream to the program; it is attached to the standard input (that is, the keyboard). When the user types characters on the keyboard, the characters flow into the stream inFromUser. The stream inFromServer is another input stream to the program; it is attached to the socket. Characters that arrive from the network flow into the stream inFromServer. Finally, the stream outToServer is an output stream from the program; it is also attached to the socket. Characters that the client sends to the network flow into the stream outToServer. Let's now take a look at the various lines in the code. import java.io.*; import java.net.*; java.io and java.net are java packages. The java.io package contains classes for input and output streams. In particular, the java.io package contains the BufferedReader and DataOutputStream classes, classes that the program uses to create the three streams previously illustrated. The java.net package provides classes for network support. In particular, it contains the Socket and ServerSocket classes. The clientSocket object of this program is derived from the Socket class. class TCPClient { public static void main(String argv[]) throws Exception {......}} So far, what we've seen is standard stuff that you see at the beginning of most Java code. The first line is the beginning of a class definition block. The keyword class begins the class definition for the class named TCPClient. A class contains variables and methods. The variables and methods of the class are embraced by the curly brackets that begin and end the class definition block. The class TCPClient has no class variables and exactly one method, the main() method. Methods are similar to the functions or procedures in languages such as C; the main method in the Java language is similar to the main function in C and C++. When the Java interpreter executes an application (by being invoked upon the application's controlling class), it starts by calling the class's main method. The main method then calls all the other methods required to run the application. For this introduction into socket programming in Java, you may ignore the keywords public, static , void, main, and throws Exceptions (although you must include them in the code).

45

Example: Java client (TCP)


import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; Create input stream Create client socket, connect to server Create output stream attached to socket

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());
2: Application Layer

port 2222

46

String sentence; String modifiedSentence; These above two lines declare objects of type String. The object sentence is the string typed by the user and sent to the server. The object modifiedSentence is the string obtained from the server and sent to the user's standard output. The above line creates the stream object inFromUser of type Buffered Reader. The input stream is initialized with System.in , which attaches the stream to the standard input. The command allows the client to read text from its keyboard. Socket clientSocket = new Socket("hostname", 6789); The above line creates the object clientSocket of type Socket. It also initiates the TCP connection between client and server. The string "hostname" must be replaced with the host name of the server (for example, "fling. seas.upenn.edu"). Before the TCP connection is actually initiated, the client performs a DNS look-up on the hostname to obtain the host's IP address. The number 6789 is the port number. You can use a different port number; but you must make sure that you use the same port number at the server side of the application. As discussed earlier, the host's IP address along with the application's port number identifies the server process. DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); BufferedReader inFromServer = new BufferedReader(new inputStreamReader(clientSocket.getInputStream())); The above two lines create stream objects that are attached to the socket. The outToServer stream provides the process output to the socket. The inFromServer stream provides the process input from the socket .

46

Example: Java client (TCP), cont.


Create input stream attached to socket

port 2222
BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine();

Send line to server Read line from server

outToServer.writeBytes(sentence + '\n');

aaaa

modifiedSentence = inFromServer.readLine();AAAA System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } }


2: Application Layer 47

sentence = inFromUser.readLine(); The above line places a line typed by the user into the string sentence . The string sentence continues to gather characters until the user ends the line by typing a carriage return. The line passes from standard input through the stream inFromUser into the string sentence. outToServer.writeBytes(sentence + '\n'); The above line sends the string sentence augmented with a carriage return into the outToServer stream. The augmented sentence flows through the client's socket and into the TCP pipe. The client then waits to receive characters from the s erver. modifiedSentence = inFromServer.readLine(); When characters arrive from the server, they flow through the stream inFromServer and get placed into the string modifiedSentence . Characters continue to accumulate in modifiedSentence until the line ends with a carriage return character. System.out.println("FROM SERVER " + modifiedSentence); The above line prints to the monitor the string modifiedSentence returned by the server. clientSocket.close(); This last line closes the socket and, hence, closes the TCP connection between the client and the server. It causes TCP in the client to send a TCP message to TCP in the server

47

Example: Java server (TCP)


import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;

Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket

port 6789

ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = port 3333 new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
2: Application Layer 48

no multithread

TCPServer has many similarities with TCPClient. Let's now take a look at the lines in TCPServer.java. We will not comment on the lines that are identical or similar t o commands in TCPClient.java. The first line in TCPServer that is substantially different from what we saw in TCPClient is: ServerSocket welcomeSocket = new ServerSocket(6789); That line creates the object welcomeSocket, which is of type ServerSocket. The WelcomeSocket, as discussed above, is a sort of door that waits for a knock f rom some client. The port number 6789 identifies the process at the server. The next line is : Socket connectionSocket = welcomeSocket.accept(); This line creates a new socket, called connectionSocket, when some client knocks on welcomeSocket. TCP then establishes a direct virtual pipe between clientSocket at the client and connectionSocket at the server. The client and server can then send bytes to each other over the pipe, and all bytes sent arrive at the other side in order. With connectionSocket established, the server can continue to listen for other requests from other clients for the application using welcomeSocket. (This version of the program doesn't actually listen for more connection requests, but it can be modified with threads to do so.) The program then creates several stream objects, analogous to the stream objects created in clientSocket.

48

Example: Java server (TCP), cont


Create output stream, attached to socket Read in line from socket Write out line to socket } } End of while loop, loop back and wait for another client connection

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine();

aaaa AAAA

capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); }

2: Application Layer

49

Now consider: capitalizedSentence = clientSentence.toUpperCase() + '\n'; This command is the heart of the application. It takes the line sent by the client, capitalizes it, and adds a carriage return. It uses the method toUpperCase(). All the other commands in the program are peripheral; they are used for communication with the client. To test the program pair, you install and compile TCPClient.java in one host and TCPServer.java in another host. Be sure to include the proper host name of the server in TCPClient.java. You then execute TCPServer.class, the compiled server program, in the server. This creates a process in the server that idles until it is contacted by some client. Then you execute TCPClient.class, the compiled client program, in the client. This creates a process in the client and establishes a TCP connection between the client and server processes. Finally, to use the application, you type a sentence followed by a carriage return. To develop your own client/server application, you can begin by slightly modifying the programs. For example, instead of converting all the letters to uppercase, the server can count the number of times the letter "s" appears and return this number.

49

Socket programming with UDP


UDP: no connection between client and server
r no handshaking r sender explicitly attaches

IP address and port of destination r receiver must extract IP address, port of sender from received datagram

application viewpoint UDP provides unreliable transfer of groups of bytes (datagrams) between client and server

UDP: transmitted data may be received out of order, or lost

2: Application Layer

50

When two processes communicate over TCP, from the perspective of the processes it is as if there is a pipe between the two processes. This pipe remains in place until one of the two processes closes it. When one of the processes wants to send some bytes to the other process, it simply inserts the bytes into the pipe. The sending process does not have to attach a destination address to the bytes because the pipe is logically connected to the destination. Furthermore, the pipe provides a reliable byte stream channel--the sequence of bytes received by the receiving process is exactly the sequence of bytes that the sender inserted into the pipe. UDP also allows two (or more) processes running on different hosts to communicate. However, UDP differs from TCP in many fundamental ways. First, UDP is a connectionless service--there isn't an initial handshaking phase during which a pipe is established between the two processes. Because UDP doesn't have a pipe, when a process wants to send a batch of bytes to another process, the sending process must attach the destination process's address to the batch of bytes. And this must be done for each batch of bytes the sending process sends. Thus, UDP is similar to a taxi service--each time a group of people get in a taxi, the group has to inform the driver of the destination address. As with TCP, the destination address is a tuple consisting of the IP address of the destination host and the port number of the destination process. We shall refer to the batch of information bytes along with the IP destination address and port number as the "packet." After having created a packet, the sending process pushes the packet into the network through a socket. Continuing with our taxi analogy, at the other side of the socket, there is a taxi waiting for the packet. The taxi then drives the packet in the direction of the packet's destination address. However, the taxi does not guarantee that it will eventually get the datagram to its ultimate destination; the taxi could break down. In other terms, UDP provides an unreliable transport service to its communication processes --it makes no guarantees that a datagram will reach its ultimate destination

50

Client/server socket interaction: UDP


Server
(running on hostid)

Client
create socket, clientSocket = DatagramSocket()

no special socket for this client NO PIPE read request from ESTABLISHED serverSocket
write reply to serverSocket specifying client host address, port umber

create socket, port=x, for incoming request: serverSocket = DatagramSocket()

port x

client socket on default local port port e.g. 2222 2222

Create, address (hostid, port=x send datagram request using clientSocket

read reply from clientSocket close clientSocket

2: Application Layer

51

Now we will illustrate UDP client-server programming by redeveloping the same application of the previous section, but this time over UDP. We shall also see that the Java code for UDP is different from the TCP code in many important ways. In particular, we shall see that there is (1) no initial handshaking between the two processes and therefore no need for a welcoming socket, (2) no streams are attached to the sockets, (3) the sending hosts create packets by attaching the IP destination address and port number to each batch of bytes it sends, and (4) the receiving process must unravel each received packet to obtain the packet's information bytes. Recall once again our simple application: A client reads a line from its standard input (keyboard) and sends the line out its socket to the server. The server reads a line from its socket. The server converts the line to uppercase. The server sends the modified line out its socket to the client. The client reads the modified line through its socket and prints the line on its standard output (monitor).

51

DatagramPacket Class
r Used for both client

and server r An independent message (datagram packet) is created using a DatagramPacket() constructor r 4 constructors

java.lang.Object | +--java.net.DatagramPacket

public final class DatagramPacket extends Object

2: Application Layer

52

The java.net package contains two classes to help you write Java programs that use datagrams to send and receive packets over the network: DatagramSocket, DatagramPacket, and MulticastSocket. An application can send and receive DatagramPackets through a DatagramSocket. In addition, DatagramPackets can be broadcast to multiple recipients all listening to a MulticastSocket. This class represents a datagram packet. A datagram is an independent, self-contained message sent over the network whose arrival, arrival time, and content are not guaranteed. Datagram packets are used to implement a connectionless packet delivery service. Each message is routed from one machine to another based solely on information contained within that packet. Multiple packets sent from one machine to another m ight be routed differently, and might arrive in any order. Note that with the Javas class of DatagramPacket a UDP address is specified by an internet address, a port number and the object DatagramPacket itself. This correspond to the C specification of sockaddr (address family, protocol, internet address, port number). CONSTRUCTORS DatagramPacket(byte[] buf, int length) Constructs a DatagramPacket for receiving packets of length length. DatagramPacket(byte[] buf, int length, InetAddress address, int port) Constructs a datagram packet for sending packets of length length to the specified port number on the specified host. DatagramPacket(byte[] buf, int offset, int length) Constructs a DatagramPacket for receiving packets of length length, specifying an offset into the buffer. DatagramPacket(byte[] buf, int offset, int length, InetAddress address, int port) Constructs a datagram packet for sending packets of length length with offset ioffsetto the specified port number on the specified host.

52

Constructors

receiving datagram packets

data length

qDatagramPacket(byte[] buf, int length)


sending datagram packets address

data <= stored in buffer data buf starts length buf.length(-offset) from offset

qDatagramPacket(byte[] buf, int offset, remote port int length) remote host qDatagramPacket(byte[] buf, int length, InetAddress address, int port) qDatagramPacket(byte[] buf, int offset, int length, InetAddress address, int port)
2: Application Layer 53

public DatagramSocket() throws SocketException Constructs a datagram socket and binds it to any available port on the local host machine. If there is a security manager, its checkListen method is first called with 0 as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public DatagramSocket(int port) throws SocketException Constructs a datagram socket and binds it to the specified port on the local host machine. If there is a security manager, its checkListen method is first called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public DatagramSocket(int port, InetAddress laddr) throws SocketException Creates a datagram socket, bound to the specified local address. The local port must be between 0 and 65535 inclusive. If there is a security manager, its checkListen method is first called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation.

53

changing after packet creation q InetAddress getAddress() getting information

Methods

q byte[] getData() source if receiving q int getLength() dest. if sending q int getOffset() q int getPort() q void setAddress(InetAddress iaddr) q void setData(byte[] buf) q void setData(byte[] buf, int offset, int length) q void setLength(int length) q void setPort(int iport)
2: Application Layer

54

METHODS InetAddress getAddress() Returns the IP address of the machine to which this datagram is being sent or from which the datagram was received. byte[] getData() Returns the data received or the data to be sent. int getLength() Returns the length of the data to be sent or the length of the data received. int getOffset() Returns the offset of the data to be sent or the offset of the data received. int getPort() Returns the port number on the remote host to which this datagram is being sent or from which the datagram was received. void setAddress(InetAddress iaddr) Set the local IP address for this packet void setData(byte[] buf) Set the data buffer for this packet. void setData(byte[] buf, int offset, int length) Set the data buffer for this packet. void setLength(int length) Set the length for this packet. void setPort(int iport) Set the local port number for this packet.

54

DatagramSocket Class

r Used for both client and

java.lang.Object | +--java.net.DatagramSocket

server r New socket is created using a DatagramSocket() constructor r 3 constructors

public class DatagramSocket extends Object

2: Application Layer

55

The public class DatagramSocket (extends Object) implements sockets for sending and receiving datagram packets. A datagram socket is the sending or receiving point for a packet delivery service. Each packet sent or received on a datagram socket is individually addressed and routed. Multiple packets sent from one machine to another may be routed differently, and may arrive in any order. UDP broadcasts sends and receives are always enabled on a DatagramSocket. The server side listens to its DatagramSocket and sends data to a client whenever the client requests it. The client side is a simple program that simply makes a request of the server. There are three public Datagram constructors. Note that the host (InetAddress or String) and the port (int value between 0 and 65,535) you want to connect to are specified in the DatagramPacket. Two of the constructor specifies also the local port from which the data will be sent (useful for host with multiple interfaces), and one the local address. CONSTRUCTORS DatagramSocket() Constructs a datagram socket and binds it to any available port on the local host machine. DatagramSocket(int port) Constructs a datagram socket and binds it to the specified port on the local host machine. DatagramSocket(int port, InetAddress laddr) Creates a datagram socket, bound to the specified local address.

55

Constructors

anonymous port

on local port r public DatagramSocket() Listen throws

SocketException SocketException

r public DatagramSocket(int port) throws


local interface address

r public DatagramSocket(int port,

InetAddress laddr) throws SocketException

2: Application Layer

56

public DatagramSocket() throws SocketException Constructs a datagram socket and binds it to any available port on the local host machine. If there is a security manager, its checkListen method is first called with 0 as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public DatagramSocket(int port) throws SocketException Constructs a datagram socket and binds it to the specified port on the local host machine. If there is a security manager, its checkListen method is first called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation. public DatagramSocket(int port, InetAddress laddr) throws SocketException Creates a datagram socket, bound to the specified local address. The local port must be between 0 and 65535 inclusive. If there is a security manager, its checkListen method is first called with the port argument as its argument to ensure the operation is allowed. This could result in a SecurityException. Throws : SocketException - if the socket could not be opened, or the socket could not bind to the specified local port; SecurityException - if a security manager exists and its checkListen method doesn't allow the operation.

56

Main Methods
blocking as accept()

send and receive to/from multiple hosts at the same time

r void receive(DatagramPacket p) r void send(DatagramPacket p) r InetAddress getLocalAddress() r int getLocalPort() r void close()

2: Application Layer

57

public void send(DatagramPacket p) throws IOException Sends a datagram packet from this socket. The DatagramPacket includes information indicating the data to be sent, its length, the IP address of the remote host, and the port number on the remote host. If there is a security manager, and the socket is not currently connected to a remote address, this method first performs some security checks. First, if p.getAddress().isMulticastAddress() is true, this method calls the security manager's checkMulticast method with p.getAddress() as its argument. If the evaluation of that expression is false, this method instead calls the security manager's checkConnect method with arguments p.getAddress().getHostAddress() and p.getPort(). Each call to a security manager method could result in a SecurityException if the operation is not allowed. Throws : IOException - if an I/O error occurs; SecurityException - if a security manager exists and its checkMulticast or checkConnect method doesn't allow the send. public void receive(DatagramPacket p) throws IOException Receives a datagram packet from this socket. When this method returns, the DatagramPacket's buffer is filled with the data received. The datagram packet als o contains the sender's IP address, and the port number on the sender's machine. This method blocks until a datagram is received. The length field of the datagram packet object contains the length of the received message. If the message is longer than the packet's length, the message is truncated. If there is a security manager, a packet cannot be received if the security manager's checkAccept method does not allow it. Throws : IOException - if an I/O error occurs. public InetAddress getLocalAddress() Gets the local address to which the socket is bound. If there is a security manager, its checkConnect method is first called with the host address and -1 as its arguments to see if the operation is allowed. Throws : SecurityException - if a security manager exists and its checkConnect method doesn't allow the operation. public int getLocalPort() Returns the port number on the local host to which this socket is bound. public void close() Closes this datagram socket.

57

to handle only needed traffic


r r r r r r

Other Methods(1)
void connect(InetAddress address, int port) void disconnect() InetAddress getInetAddress() int getPort() receive() waits as read for Socket int getSoTimeout() void setSoTimeout(int timeout)

2: Application Layer

58

public void connect(InetAddress address, int port) Connects the socket to a remote address for this socket. When a socket is connected to a remote address, packets may only be sent to or received from that address. By default a datagram socket is not connected. A caller's permission to send and receive datagrams to a given host and port are checked at connect time. When a socket is connected, receive and send will not perform any security checks on incoming and outgoing packets, other than matching the packet's and the socket's address and port. On a send operation, if the packet's address is set and the packet's address and the socket's address do not match, an IllegalArgumentException will be thrown. A socket connected to a multicast address may only be used to send packets. Throws :IllegalArgumentException - if the address is invalid or the port is out of range; SecurityException - if the caller is not allowed to send datagrams to and receive datagrams from the address and port. public void disconnect() Disconnects the socket. This does nothing if the socket is not connected. public InetAddress getInetAddress() Returns the address to which this socket is connected. Returns null if the socket is not connected. public int getPort() Returns the port for this socket. Returns -1 if the socket is not connected. public int getSoTimeout() throws SocketException Retrive setting for SO_TIMEOUT. 0 returns implies that the option is disabled (i.e., timeout of infinity). public void setSoTimeout(int timeout) throws SocketException Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a call to receive() for this DatagramSocket will block for only this amount of time. If the timeout expires, a java.io.InterruptedIOException is raised, though the ServerSocket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

58

Other Methods(2)
int getReceiveBufferSize() r int getSendBufferSize() r void setReceiveBufferSize(int size) r void setSendBufferSize(int size)
r

2: Application Layer

59

public void setReceiveBufferSize(int size) throws SocketException Sets the SO_RCVBUF option to the specified value for this DatagramSocket. The SO_RCVBUF option is used by the platform's networking code as a hint for the size to use to allocate set the underlying network I/O buffers. Increasing buffer size can increase the performance of network I/O for high-volume connection, while decreasing it can help reduce the backlog of incoming data. For UDP, this sets the maximum size of a packet that may be sent on this socket. Since SO_RCVBUF is a hint, applications that want to verify what size the buffers were set to should call IllegalArgumentException - if the value is 0 or is negative. public int getSendBufferSize() throws SocketException Get value of the SO_SNDBUF option for this socket, that is the buffer size used by the platform for output on the this Socket. public int getReceiveBufferSize() throws SocketException Get value of the SO_RCVBUF option for this socket, that is the buffer size used by the platform for input on the this Socket. public void setSendBufferSize(int size) throws SocketException Sets the SO_SNDBUF option to the specified value for this DatagramSocket. The SO_SNDBUF option is used by the platform's networking code as a hint for the size to use to allocate set the underlying network I/O buffers. Increasing buffer size can increase the performance of network I/O for high-volume connection, while decreasing it can help reduce the backlog of incoming data. For UDP, this sets the maximum size of a packet that may be sent on this socket. Because SO_SNDBUF is a hint, applications that want to verify what size the buffers were set to should call IllegalArgumentException - if the value is 0 or is negative.

59

Example: Java client (UDP)

2: Application Layer

60

The program UDPClient.java constructs one stream and one socket.

60

Example: Java server (UDP)

2: Application Layer

61

The program UDPServer.java constructs one socket. The socket is called serverSocket. It is an object of type DatagramSocket, as was the socket in the client side of the application. Once again, no streams are attached to the socket.

61

Example: Java client (UDP)


import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception port {

Create input stream

2222

Create client socket Translate hostname to IP address using DNS Create input and output buffer

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();
2: Application Layer 62

The socket is called clientSocket , and it is of type DatagramSocket . Note that UDP uses a different kind of socket than TCP at the client. In particular, with UDP our client uses a DatagramSocket whereas with TCP our client used a Socket. The stream inFromUser is an input stream to the program; it is attached to the standard input, that is, to the keyboard. We had an equivalent stream in our TCP version of the program. When the user types characters on the keyboard, the characters flow into the stream inFromUser. But in contrast with TCP, there are no streams (input or output) attached to the socket. Instead of feeding bytes to the stream attached to a Socket object, UDP will push individual packets through the DatagramSocket object. Let's now take a look at the lines in the code that differ significantly from TCPClient .java . DatagramSocket clientSocket = new DatagramSocket(); The previous line creates the object clientSocket of type DatagramSocket . In contrast with TCPClient.java, this line does not initiate a TCP connection. In particular, the client host does not contact the server host upon execution of this line. For this reason, the constructor DatagramSocket () does not take the server hostname or port number as arguments. Using our door/pipe analogy, the execution of the above line creates a door for the client process but does not create a pipe between the two processes. InetAddress IPAddress = InetAddress.getByName ("hostname"); In order to send bytes to a destination process, we shall need to obtain the address of the process. Part of this address is the IP address of the destination host. The above line invokes a DNS look-up that translates the hostname (in this example, supplied in the code by the developer) to an IP address. DNS was also invoked by the TCP version of the client, although it was done there implicitly rather than explicitly. The method getByName() takes as an argument the hostname of the server and returns the IP address of this same server. It places this address in the object IPAddress of type InetAddress. byte[] sendData = new byte[]; byte[] receiveData = new byte[]; The byte arrays sendData and receiveData will hold the data the client sends and receives, respectively. sendData = sentence.getBytes(); The above line essentially performs a type conversion. It takes the string sentence and renames it as sendData, which is an array of bytes.

62

Example: Java client (UDP), cont.


Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server
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(); } }
2: Application Layer 63

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); This line constructs the packet, sendPacket, that the client will pop into the network through its socket. This packet includes that data that is contained in the packet, sendData, the length of this data, the IP address of the server, and the port number of the application (which we have set to 9876). Note that sendPacket is of type DatagramPacket. clientSocket.send(sendPacket); In the above line, the method send() of the object clientSocket takes the packet just constructed and pops it into the network through clientSocket. Once again, note that UDP sends the line of characters in a manner very different from TCP. TCP simply inserted the line into a stream, which had a logical direct connection to the server; UDP creates a packet that includes the address of the server. After sending the packet, the client then waits to receive a packet from the server. DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); In the above line, while waiting for the packet from the server, the client creates a place holder for the packet, receivePacket, an object of type DatagramPacket. clientSocket.receive(receivePacket); The client idles until it receives a packet; when it does receiv e a packet, it puts the packet in receivePacket. String modifiedSentence = new String(receivePacket.getData()); The above line extracts the data from receivePacket and performs a type conversion, converting an array of bytes into the string modifiedSentence. System.out.println("FROM SERVER:" + modifiedSentence); This line, which is also present in TCPClient, prints out the string modifiedSentence at the client's monitor. clientSocket.close(); This last line closes the socket. Because UDP is connectionless, this line does not cause the client to send a transport-layer message to the server (in contrast with TCPClient).

63

Example: Java server (UDP)


import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception {

port x

Create datagram socket at port 9876

DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) {

Create space for received datagram Receive datagram

no multithread

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket);


2: Application Layer 64

Let's now take a look at the lines in the code that differ from TCPServer. java. DatagramSocket serverSocket = new DatagramSocket(9876); The above line constructs the DatagramSocket serverSocket at port 9876. All data sent and received will pass through this socket. Because UDP is connectionless, we do not have to spawn a new socket and continue to listen for new connection requests, as done in TCPServer.java. If multiple clients access this application, they will all send their packets into this single door, serverSocket.

64

Example: Java server (UDP), cont


String sentence = new String(receivePacket.getData());

Get IP addr port #, of sender

InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes();

Create datagram to send to client Write out datagram to socket


} }

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); }

End of while loop, loop back and wait for another datagram

2: Application Layer

65

String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); The above three lines unravel the packet that arrives from the client. The first of the three lines extracts the data from the packet and places the data in the String sentence; it has an analogous line in UDPClient. The second line extracts the IP address; the third line extracts the client port number, which is chosen by the client and is different from the server port number 9876. (We will discuss client port numbers in some detail in the next chapter.) It is necessary for the server to obtain the address (IP address and port number) of the client, so that it can send the capitalized sentence back to the client. That completes our analysis of the UDP program pair. To test the application, you install and compile UDPClient.java in one host and UDPServer.java in another host. (Be sure to include the proper hostname of the server in UDPClient.java.) Then execute the two programs on their respective hosts. Unlike with TCP, you can first execute the client side and then the server side. This is because, when you execute the client side, the client process does not attempt to initiate a connection with the server. Once you have executed the client and server programs, you may use the application by typing a line at the client.

65

Socket Programming (TCP & UDP)


r TCP
Server process must first be running and Server process must first be running and created welcome socket created server socket Client creates client-local TCP socket Client creates client-local socket and specifying IP address, port number of group data in packets specifying each server process at welcome socket IP address, port number of server process at server socket Client TCP connects to server TCP UDP provides unreliable transfer of Server creates new TCP socket for datagrams between client and server server process to communicate with Client and Server processes uses client datagrams for input and output data TCP provides reliable, in-order transfer Java has 2 classes for UDP sockets: of bytes between client and server DatagramSocket and DatagramPacket Client and Server processes uses streams for input and output data Java has 2 classes for TCP sockets: Socket and ServerSocket
2: Application Layer 66

r UDP

66

Multicast Sockets
r Multicast = send to a group m used for: conferencing, radio distribution, m multicast IP addresses are logical (= non topological) m for receiving data sent to multicast address m, a host must subscribe to m m for sending to multicast address m, a host simply writes m in the dest addr field r MulticastSocket DatagramSocket with joining group capabilities r Java offers two public constructors
2: Application Layer 67

A number of emerging network applications require the delivery of packets from one or more senders to a group of receivers. For each of these applications, an extremely useful abstraction is the notion of a multicast: the sending of a packet from one sender to multiple receivers with a single send operation. Clearly, this second approach toward multicast makes more efficient use of network bandwidth in that only a single copy of a datagram will ever traverse a link. On the other hand, considerable network layer support is needed to implement a multicast-aware network layer. Internet multicast is not a connectionless service--state information for a multicast connection must be established and maintained in routers that handle multicast packets sent among hosts in a so-called multicast group. This, in turn, will require a combination of signaling and routing protocols in order to set up, maintain, and tear down connection state in the routers. in the Internet architecture (and the ATM architecture as well), a multicast datagram is addressed using address indirection. That is, a single identifier is used for the group of receivers, and a copy of the datagram that is addressed to the group using this single identifier is delivered to all of the multicast receivers associated with that group. In the Internet, the single identifier that represents a group of receivers is a Class D multicast address. The group of receivers associated with a class D address is refe rred to as a multicast group. Multicast addresses are not allocated on a geographical basis. A global allocation scheme is under discussion at the IETF. Today, global scope addresses are allocated using the sd tool on Unix. Note that the unique IP unicast address of an host is completely independent of the address of the multicast group in which it is participating.

67

Chapter 2: Summary
Our study of network apps now complete!
r application service

requirements:
m

specific protocols:
m m m

reliability, bandwidth, delay

http ftp smtp client/server implementation using tcp, udp sockets

r client-server paradigm r Internet transport service

model
m m

socket programming
m m

connection-oriented, reliable: TCP unreliable, datagrams: UDP

2: Application Layer

68

68

Some information
r Project m 1st part due next week r Survey m Feedbacks next week r Material (Java files, Exercises2): m http://lrcwww.epfl.ch/~giordano/Cours2001/
UDPJava.tar Exe2.ppt

2: Application Layer

69

69

Last Week
Our study of network apps started
r

application elements:
m m
m

user agent process API

Internet transport service model


m m

application-layer protocol

connection-oriented, reliable: TCP unreliable, datagrams: UDP http - WEB ftp File Transfer smtp - Email

application service requirements:


m

client-server paradigm

reliability, bandwidth, delay

specific protocols:
m m m

2: Application Layer

70

70

You might also like