Chapter 3 Network Programming and Applications Topics Covered • • • • • • • • Client-Server Computing Communication Paradigm An Example Application Program Interface Definition Of The API An Echo Application A Chat Application A Web Application Managing.

Download Report

Transcript Chapter 3 Network Programming and Applications Topics Covered • • • • • • • • Client-Server Computing Communication Paradigm An Example Application Program Interface Definition Of The API An Echo Application A Chat Application A Web Application Managing.

Chapter 3
Network Programming
and
Applications
Topics Covered
•
•
•
•
•
•
•
•
Client-Server Computing
Communication Paradigm
An Example Application Program Interface
Definition Of The API
An Echo Application
A Chat Application
A Web Application
Managing Multiple Connections With The Select
Function
Network Communication
• Applications us a network in pairs to exchange
messages
• Example
– A distributed database service that allows remote
users to access a central database
• One application runs on a remote computer to
send request
• The other application on the computer that has
the databases to send a response
• Only the two applications understand the
message format and meaning
Client-Server Computing (1)
• One application starts first and waits for the
other application to contact it
• The second application must know the location
where the first application is waiting
• This is known as client-server computing
• The program that waits for contact is called a
server
• The program that initiates contact is known as a
client who must know where the server is
running, and must specify the location
Client-Server Computing (2)
How does a client specify the location of a server?
• In the Internet, a location is given by a pair of
identifiers
– (computer, application)
– computer identifies the computer on which the server
is running
– application identifies a particular application program
on that computer
• Humans enter the names (i.e. echo), and
software translates each name to a
corresponding binary value automatically
because application software use binary value
Communication Paradigm
• Two applications
– establish communication,
– exchange messages back and forth,
– and then terminate
• The steps (in details) are:
– The server starts first, and waits for contact from a client
– The client specifies the server's location and requests a
connection be established
– Once a connection is in place, the client and server use the
connection to exchange messages
– After they finish sending data, the client and server each send an
end-of-file (EOF) and the connection is terminated
An Example Application Program
Interface
• Application Program Interface (API) is used to describe
the set of operations available to a programmer
• Seven functions that an application can call
An Intuitive Look At The API
•
•
•
•
•
•
A server begins by calling await_contact to wait for contact from a client
The client begins by calling make_contact to establish contact
Once the client has contacted the server, the two can exchange messages with
send and recv
Order of send or receive must be known by server and client, if both sides try to
receive without sending, they will block forever
An application calls send_eof to terminate the communication
On the other side, recv returns a value of zero to indicate the termination
Definition Of The API
• Define 3 data types to keep our API independent
of particular OS and NW software
Functions
• Await_Contact Function: connection await_contact(appnum a)
– A server calls function await_contact to wait for contact from a client
– One argument specifies a number that identifies the server application
and a client must specify the same number when contacting the server.
– The server uses the return value (type connection ) to transfer data
• Make_Contact Function: connection make_contact (computer c,
appnum a)
– client calls function make_contact to establish contact with a server
– Two arguments to identify a computer of the server application number
– The client uses the return value which is of type connection to transfer
data
Functions
• appnum appname_to_appnum(char *a)
– Clients and servers both use it to translate from a
human-readable service name for a service to an
internal binary value
– The call takes one argument and returns an
equivalent binary value of type appnum
• computer cname_to_comp (char *c)
– Clients call it to convert from a human-readable
computer name to the internal binary value
– The call takes one argument and returns an
equivalent binary value of type computer
Functions
•
int send (connection con, char *buffer, int length, int flags)
– Both clients and servers use send to transfer data across the network
– Four arguments specifies a connection previously established with await_contact or
make_contact; the address of a buffer containing data to send; the length of the data
in bytes (octets); the fourth argument is zero for normal transfer
– Send returns the number of bytes transferred, or a negative value if an error occurred
•
int recv (connection con, char *buffer, int length, int flags)
– Both clients and servers use recv to access data that arrives
– Four arguments specifies: a connection with await_contact or make_contact; the
address of a buffer into which the data to be placed; the size of the buffer in bytes;
and the fourth is zero for normal transfer
– recv returns the number of bytes that were placed in the buffer
– zero to indicate that EOF has been reached or a negative value to indicate that an
error occurred
•
int recvln (connection con, char *buffer, int length)
– function recvln that repeatedly calls recv until an entire line of text has been
received.
Functions
• Both the client and server must use send_eof after
sending data
– to inform the other side that no further transmission will occur
• On the other side, the recv function returns zero when
it receives the EOF
int send_eof(connection con)
• Argument specifies a connection previously established
with await_contact or make_contact
• The function returns a negative value
– to indicate that an error occurred, and a non-negative value
otherwise
Code For An Echo Application (1)
• The client repeatedly
– prompts the user for a line of input,
– sends the line to the server,
– and then displays whatever the server sends back.
• Like all the applications described in this
chapter,
– the echo application operates across a NW
– That is, the client and server programs can run on
separate computers
Code For An Echo Application (2)
• Ex: suppose someone using computer
lancelot.cs.purdue.edu chooses 20000 as the
application number
• The server is invoked by the command:
echoserver 20000
• If some other application is using number 20000,
– the server emits an appropriate error message and exits
– the user must choose another number.
• Once the server has been invoked, the client is invoked:
echoclient lancelot.cs.purdue.edu 20000
Code For A Chat Application
• A simplified version of chat that works between a single
pair of users
• One user begins by choosing an application number and
running the server
• Ex: suppose a user on excalibur.cs.purdue.edu runs the
server:
chatserver 25000
• A user on another computer can invoke the client:
chatclient excalibur.cs.purdue.edu 25000
• To keep the code as small as possible
– the scheme requires users to take turns entering text
– Users alternate entering text until one of them sends an EOF
Code for Web Application
Browser Interface
• The World Wide Web (WWW) is the
large-scale, online repository of
information
• A browser is an interactive program used
to access the Web
• Web is a “distributed” “hypermedia”
system that supports interactive access
because a browser can display both text
and graphics.
Document Representation
• Web uses a standard representation known as
the HyperText Markup Language (HTML)
• HTML is classified as a “markup language”
– because it only gives general guidelines for display
– but does not include detailed formatting instructions
• Markup language is important because it allows
a browser to adapt the page to the underlying
display: Thus, the same page can be formatted
for
– a large or small computer monitor
– a high resolution or low resolution display
– or a handheld device such as a PDA
HTML Format And Representation
• Each HTML document
is divided into
– a head that contains
information about the
document
– a body that contains the
information to be
displayed
• HTML tags provide
structure for the
document as well as
formatting
Other Markup Languages
Other markup languages have been created for
special purposes.
• Voice Extensible Markup Language (VoiceXML)
or VXML
– specifies communication in human speech
• Extensible Markup Language (XML)
– Unlike HTML, XML does not specify layout
– Instead, XML gives an internal representation that
provides names for each field in a data item
Web and HTTP
First some jargon
• Web page consists of objects
• Object can be HTML file, JPEG image, Java
applet, audio file,…
• Web page consists of base HTML-file which
includes several referenced objects
• Each object is addressable by a URL
• Example URL:
www.someschool.edu/someDept/pic.gif
host name
path name
HTTP overview
HTTP: hypertext transfer
protocol
• Web’s application layer
protocol
• client/server model
– client: browser that
requests, receives,
“displays” Web objects
– server: Web server sends
objects in response to
requests
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
HTTP overview (continued)
Uses TCP:
• client initiates TCP
connection (creates
socket) to server, port 80
• server accepts TCP
connection from client
• HTTP messages
(application-layer protocol
messages) exchanged
between browser (HTTP
client) and Web server
(HTTP server)
• TCP connection closed
HTTP is “stateless”
• server maintains no
information about
past client requests
aside
Protocols that maintain “state” are
complex!
• past history (state) must be
maintained
• if server/client crashes, their
views of “state” may be
inconsistent, must be
reconciled
HTTP connections
Nonpersistent HTTP
• At most one object is
sent over a TCP
connection.
• HTTP/1.0 uses
nonpersistent HTTP
Persistent HTTP
• Multiple objects can
be sent over single
TCP connection
between client and
server.
• HTTP/1.1 uses
persistent
connections in default
mode
Nonpersistent HTTP
Suppose user enters URL
(contains text,
references to 10
jpeg images)
www.someSchool.edu/someDepartment/home.ind
ex
1a. HTTP client initiates TCP
1b. HTTP server at host
connection to HTTP server
(process) at
www.someSchool.edu on port
80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.inde
x
time
www.someSchool.edu
waiting for TCP connection
at port 80. “accepts”
connection, notifying client
3. HTTP server receives
request message, forms
response message
containing requested object,
and sends message into its
socket
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
5. HTTP client receives response
time
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
6. Steps 1-5 repeated for each
of 10 jpeg objects
connection.
Response time modeling
Definition of RRT: time to
send a small packet to
travel from client to server
and back.
Response time:
• one RTT to initiate TCP
connection
• one RTT for HTTP
request and first few bytes
of HTTP response to
return
• file transmission time
total = 2RTT+transmit time
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
file
received
time
time
Persistent HTTP
Nonpersistent HTTP issues:
• requires 2 RTTs per object
• OS must work and allocate
host resources for each TCP
connection
• but browsers often open
parallel TCP connections to
fetch referenced objects
Persistent HTTP
• server leaves connection
open after sending response
• subsequent HTTP messages
between same client/server
are sent over connection
Persistent without pipelining:
• client issues new request
only when previous
response has been received
• one RTT for each referenced
object
Persistent with pipelining:
• default in HTTP/1.1
• client sends requests as
soon as it encounters a
referenced object
• as little as one RTT for all
the referenced objects
HTTP request message
• two types of HTTP messages: request, response
• HTTP request message:
– ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
HTTP request message: general format
Uploading form input
Post method:
URL method:
• Web page often
includes form input • Uses GET method
• Input is uploaded to • Input is uploaded in
server in entity body URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana
Method types
HTTP/1.0
• GET requests a specified
item from the server
• POST sends data to the
server
– The server appends the
data to a specified item
• HEAD requests status
information about an item
– The server returns the
status without returning a
copy of the item itself
HTTP/1.1
• GET, POST, HEAD
• PUT sends data to the
server
– The server uses the data to
replace a specified item .
– It is seldom used; most
Web pages that send data
use POST instead
• DELETE
– deletes file specified in the
URL field
HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
HTTP response status codes
In first line in server->client response message.
A few sample codes:
200 OK
– request succeeded, requested object later in this message
301 Moved Permanently
– requested object moved, new location specified later in
this message (Location:)
400 Bad Request
– request message not understood by server
404 Not Found
– requested document not found on this server
505 HTTP Version Not Supported
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet cis.poly.edu 80
Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu
2. Type in a GET HTTP request:
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
3. Look at response message sent by HTTP
server!
35.18 Alternative Transfer
Protocols
• Several extensions and alternatives have been proposed
to enhance or replace HTTP
• HTTPS
– protocol provides for secure HTTP transfers
• (i.e., it uses encryption to guarantee confidentiality of the data being
transferred in an HTTP session)
• HTTP version 1.1 introduces the concept of persistent
connections
– in which a single TCP connection is used for multiple transfers
• (i.e., multiple GET requests from the browser).
• HTTP-NG (Next-Generation of HTTP)
– that will use binary encoding for headers instead of the current
ASCII representation
User-server state: cookies
Many major Web sites use
cookies
Four components:
1) cookie header line in the
HTTP response message
2) cookie header line in HTTP
request message
3) cookie file kept on user’s
host and managed by
user’s browser
4) back-end database at Web
site
Example:
– Susan access Internet
always from same PC
– She visits a specific ecommerce site for first
time
– When initial HTTP
requests arrives at
site, site creates a
unique ID and creates
an entry in backend
database for ID
Cookies: keeping “state” (cont.)
client
Cookie file
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
one week later:
Cookie file
amazon: 1678
ebay: 8734
server
usual http request msg
usual http response +
Set-cookie: 1678
usual http request msg
cookie: 1678
usual http response msg
usual http request msg
cookie: 1678
usual http response msg
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
Cookies (continued)
aside
What cookies can
bring:
• authorization
• shopping carts
• recommendations
• user session state
(Web e-mail)
Cookies and privacy:
• cookies permit sites to
learn a lot about you
• you may supply name
and e-mail to sites
• search engines use
redirection & cookies to
learn yet more
• advertising companies
obtain info across sites
Web caches (proxy server)
Goal: satisfy client request without involving origin
server
• user sets browser:
Web accesses via
cache
• browser sends all
HTTP requests to
cache
– object in cache: cache
returns object
– else cache requests
object from origin server,
then returns object to
client
origin
server
client
client
Proxy
server
origin
server
More about Web caching
• Cache acts as both client
and server
• Typically cache is
installed by ISP
(university, company,
residential ISP)
Why Web caching?
• Reduce response time for
client request.
• Reduce traffic on an
institution’s access link.
• Internet dense with
caches enables “poor”
content providers to
effectively deliver content
(but so does P2P file
sharing)
Caching example
Assumptions
• average object size = 100,000
bits
• avg. request rate from
institution’s browsers to origin
servers = 15/sec
• delay from institutional router to
any origin server and back to
router = 2 sec
Consequences
•
•
•
utilization on LAN = 15%
utilization on access link = 100%
total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes + milliseconds
origin
servers
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Caching example (cont)
Possible solution
• increase bandwidth of
access link to, say, 10
Mbps
Consequences
• utilization on LAN = 15%
• utilization on access link = 15%
• Total delay = Internet delay +
access delay + LAN delay
= 2 sec + msecs + msecs
• often a costly upgrade
origin
servers
public
Internet
10 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Caching example (cont)
origin
servers
Install cache
• suppose hit rate is .4
Consequence
• 40% requests will be satisfied
almost immediately
• 60% requests satisfied by origin
server
• utilization of access link reduced
to 60%, resulting in negligible
delays (say 10 msec)
• total avg delay = Internet delay
+ access delay + LAN delay =
.6*(2.01) secs + milliseconds <
1.4 secs
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Conditional GET
• Goal: don’t send object if cache
cache has up-to-date
HTTP request msg
cached version
If-modified-since:
<date>
• cache: specify date of
cached copy in HTTP
HTTP response
request
If-modified-since:
<date>
• server: response contains
no object if cached copy
is up-to-date:
HTTP/1.0 304 Not
Modified
server
object
not
modified
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.0 200 OK
<data>
object
modified
Code For A Web Application (1)
• To run the server, a user chooses an application number
and invokes the server
• Ex: if a user on computer netbook.cs.purdue.edu
chooses application number 27000, the server can be
invoked with the command:
webserver 27000
• The client specifies a computer, a path name, and an
application number:
webclient netbook.cs.purdue.edu /index.html
27000
• It is possible to use a conventional Web browser (such
as, Internet Explorer or Netscape) to access the server
http://netbook.cs.purdue.edu:27000/index.html
Code For A Web Application (2)
• The client code is extremely simple:
– after establishing communication with the Web server,
it sends a request, which must have the form :
GET / path HTTP/1.0 CRLF CRLF
CRLF GET
– where path denotes the name of an item such as
index.html ,
– CRLF denotes the two characters carriage return and
line feed.
• After sending the request, the client receives
and prints output from the server
Code For A Web Application (3)
• Web server may seem more complex than previous examples,
– complexity results from Web details rather than networking details
• In addition to reading and parsing a request
– the server must send both a ``header'' and data in the response
– The header consists of several lines of text that are terminated by CRLF
• The header lines are of the form:
HTTP/1.0 status status_string CRLF
Server: CNAI Demo Server CRLF
Content-Length: datasize CRLF
Content-Type: text/html CRLF
CRLF
• where datasize denotes the size of the data that follows
Code For A Web Application (4)
• The code is also complicated by error handling
– error messages must be sent in a form that a browser can
understand
• If a request is incorrectly formed, our server generates a
400 error message
• If the item specified in the request cannot be found
404 error message
• The Web server differs from the previous examples in a
significant way:
– the server program does not exit after satisfying one request
– Instead, it remains running, ready for additional requests
Managing Multiple Connections
With The Select Function (1)
• Although our example API supports 1-to-1
interaction between a client and server,
– the API does not support 1-to-many interaction
• To see why, consider multiple connections
– To create such connections
• a single application must call make_contact multiple times
• specifying a computer and appnum for each call
• Once the connections have been established
– the application cannot know which of them will
receive a message first
Managing Multiple Connections
With The Select Function (2)
• Many OS include a function named select
that solves the problem of managing
multiple connections
– The select call checks a set of connections
– The call blocks until at least one of the
specified connections has received data
– The call then returns a value that tells which
of the connections have received data
Managing Multiple Connections
With The Select Function (3)
• Ex: consider an application that must receive requests and send
responses over two connections
– Such an application can have the following general form:
Call make_contact to form connection1;
Call make_contact to form connection2;
Repeat forever {
Call select to determine which connection is ready
If (connection1 is ready) {
Call recv to read request from connection1;
Compute response to request;
Call send to send response over connection1;
} if (connection2 is ready) {
Call recv to read request from connection2;
Compute response to request;
Call send to send response over connection2; }
}