NETCENTRIC

FUNDAMENTALS (ITT501)

CHAPTER 4 –
OVERVIEW OF
NETWORKED
APPLICATION
 Chapter Outline
• Overview of application layer and
protocols
• The role of middleware
 Remote Procedure Calls (RPC)
 Web services
• Database-driven web applications
• Enterprise web based applications
Overview of application layer and
protocols

2.1 principles of 2.5 P2P applications

network 2.6 video streaming
applications and content
2.2 Web and HTTP distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket
2.4 DNS programming
with UDP and
TCP

Application Layer 2-3

Overview of application layer and protocols
Layered Internet protocol stack (TCP/IP)
▪ application: supporting network applications
• HTTP, IMAP, SMTP, DNS
application
application
▪ transport: process-process data transfer
• TCP, UDP
transport
transport
▪ network: routing of datagrams from source to
destination network
• IP, routing protocols
▪ link: data transfer between neighboring link
network elements physical
• Ethernet, 802.11 (WiFi), PPP
▪ physical: bits “on the wire”
Network Applications
 programs that run on different end systems and
communicate with each other over the network.

 Network applications are the reason of a computer network

existence.

 These applications have been the driving force behind the

Internet’s success, motivating people in homes, schools,
governments, and businesses to make the Internet an
integral part of their daily activities.

Application Layer 2-6

Some network apps
 e-mail  voice over IP
 web (e.g., Skype)
 text messaging  real-time video
 conferencing
remote login
 social networking
 P2P file sharing
 search
 multi-user
network games  …
 streaming stored  …
video (YouTube,
Hulu, Netflix)

Application Layer 2-7

Creating a network app application
transport
network
data link
physical
write programs that:
 run on (different) end
systems
 communicate over network
 e.g., web server software
communicates with browser
software

no need to write software application

transport

for network-core
network
data link application
transport
devices
physical
network
data link
 network-core devices do physical

not run user applications

 applications on end
systems allows for rapid
app development,
propagation
Application Layer 2-8
Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-9

 Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for scaling

clients:
 communicate with server
 may be intermittently
client/server connected
 may have dynamic IP
addresses
 do not communicate
directly with each other

Application Layer 2-10

P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service
from other peers,
provide service in
return to other peers
• self scalability – new
peers bring new
service capacity, as
well as new service
demands
 peers are intermittently
connected and change
IP addresses
• complex
management Application Layer 2-11
Processes communicating
process: program clients, servers
running within a client process:
host process that initiates
 within same host, two communication
processes server process:
communicate using process that waits to
inter-process be contacted
communication
(defined by OS)  aside: applications
 processes in different with P2P architectures
hosts communicate have client processes
by exchanging & server processes
messages

Application Layer 2-12

Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
• sending process shoves message out door
• sending process relies on transport infrastructure
on other side of door to deliver message to
socket at receiving process

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-13

Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated
 host device has with process on host.
unique 32-bit IP  example port numbers:
address • HTTP server: 80
 Q: does IP address of • mail server: 25
host on which process  to send HTTP message
 A: no,
runs suffice
manyfor
processes to gaia.cs.umass.edu
can be running
identifying the on web server:
same host
process? • IP address:
128.119.245.12
• port number: 80
 more shortly…

Application Layer 2-14

App-layer protocol defines
 types of messages open protocols:
exchanged,  defined in RFCs
• e.g., request,  allows for
response
interoperability
 message syntax:
 e.g., HTTP, SMTP
• what fields in
messages & how proprietary protocols:
fields are delineated  e.g., Skype
 message semantics
• meaning of
information in fields
 rules for when and how
processes send &
respond to messages

Application Layer 2-15

What transport service does an
app need?
data integrity throughput
 some apps (e.g., file  some apps (e.g.,
transfer, web transactions) multimedia) require
require 100% reliable data minimum amount of
throughput to be
transfer
“effective”
 other apps (e.g., audio)
 other apps (“elastic apps
can tolerate some loss ”) make use of whatever
timing throughput they get
 some apps (e.g.,
Internet telephony, security
interactive games)  encryption, data
require low delay to integrity, …
be “effective”

Application Layer 2-16

 Transport service requirements:
common apps

application data loss throughput time sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
text messaging no loss elastic yes and no

Application Layer 2-17

Internet transport protocols
services
TCP service: UDP service:
 reliable transport  unreliable data
between sending and transfer between
receiving process
sending and receiving
 flow control: sender won’t process
overwhelm receiver  does not provide:
 congestion control:
reliability, flow
throttle sender when control, congestion
network overloaded control, timing,
 does not provide: timing, throughput
minimum throughput guarantee, security,
guarantee, security or connection setup,
 connection-oriented:
setup required between
client and server Q: why bother? Why is
processes there a UDP?
Application Layer 2-18
Internet apps: application, transport
protocols
application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Application Layer 2-19

Overview of application layer and
protocols
2.1 principles of 2.5 P2P applications
network 2.6 video streaming
applications and content
2.2 Web and HTTP distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket
2.4 DNS programming
with UDP and
TCP

Application Layer 2-20

Web and HTTP
First, a review…
 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,
www.someschool.edu/someDept/pic.gif
e.g.,
host name path name

Application Layer 2-21

HTTP overview
HTTP: hypertext
transfer protocol
HT
 Web’s application TP
req
layer protocol PC running HT
ues
t
 client/server model Firefox browser TPr
esp
ons
• client: browser that e
requests, receives, t
(using HTTP u es
req server
protocol) and T P n se
“displays” Web HT s po running
re Apache Web
objects T TP
H server
• server: Web server
sends (using HTTP iPhone running
protocol) objects in Safari browser
response to
requests
Application Layer 2-22
HTTP overview (continued)
uses TCP: HTTP is “stateless”
 client initiates TCP  server maintains no
connection (creates information about
past client requests
socket) to server, port
80
 server accepts TCP aside
connection from client
 HTTP messages protocols that maintain
(application-layer “state” are complex!
protocol messages)  past history (state) must
exchanged between be maintained
browser (HTTP client)  if server/client crashes,
and Web server (HTTP their views of “state”
server) may be inconsistent,
 TCP connection closed must be reconciled

Application Layer 2-23

HTTP connections
non-persistent HTTP persistent HTTP
 at most one  multiple objects
object sent over can be sent over
TCP connection single TCP
• connection then connection
closed between client,
 downloading server
multiple objects
required multiple
connections

Application Layer 2-24

 Non-persistent HTTP
suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
www.someSchool.edu on www.someSchool.edu
port 80 waiting for TCP connection
at port 80. “accepts”
2. HTTP client sends HTTP request message
connection, notifying client
(containing URL) into TCP connection
socket. Message indicates that client
wants object 3. HTTP server receives
someDepartment/home.index
request message, forms
response message
containing requested
object, and sends
time message into its socket

Application Layer 2-25

 Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives
response message
containing html file,
displays html. Parsing html
file, finds 10 referenced
jpeg objects
time
6. Steps 1-5 repeated for
each of 10 jpeg objects

Application Layer 2-26

 HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
• ASCII (human-readable format)
carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
line feed at start Keep-Alive: 115\r\n
Connection: keep-alive\r\n
of line indicates \r\n
end of header lines

* Check out the online interactive exercises for more

examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-27
HTTP request message: general
format
method sp URL sp version cr lf request
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application Layer 2-28

Uploading form input
POST method:
 web page often
includes form input
 input is uploaded to
server in entity body

URL method:
 uses GET method
 input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana

Application Layer 2-29

Method
types
HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD • uploads file in
• asks server to entity body to
leave requested path specified in
object out of URL field
response  DELETE
• deletes file
specified in the
URL field

Application Layer 2-30

 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
data, e.g., \r\n
requested data data data data data ...
HTML file

* Check out the online interactive exercises for more

examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-31
HTTP response status codes
 status code appears in 1st line in server-to-client response message.
 some sample codes:

200 OK
• request succeeded, requested object later in this msg
301 Moved Permanently
• requested object moved, new location specified later in
this msg (Location:)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Application Layer 2-32
User-server state: cookies
example:
many Web sites use  Susan always access
cookies
Internet from PC
four components:
 visits specific e-
1) cookie header line
commerce site for first
of HTTP response time
message
 when initial HTTP
2) cookie header line
in next HTTP request
requests arrives at
message site, site creates:
3) cookie file kept on • unique ID
user’s host, • entry in backend
managed by user’s database for ID
browser
4) back-end database
at Web site
Application Layer 2-33
 Cookies: keeping “state” (cont.)
client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer 2-34
Cookies (continued)
aside
what cookies can cookies and privacy:
be used for:  cookies permit sites to
 authorization learn a lot about you
 shopping carts  you may supply name
 recommendations and e-mail to sites
 user session state
(Web e-mail)

how to keep “state”:

 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages carry
state
Application Layer 2-35
Overview of application layer and
protocols
2.1 principles of 2.5 P2P applications
network 2.6 video streaming
applications and content
2.2 Web and HTTP distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket
2.4 DNS programming
with UDP and
TCP

Application Layer 2-36

Pure P2P architecture
 no always-on server
 arbitrary end
systems directly
communicate
 peers are
intermittently
connected and
change IP addresses
examples:
• file distribution
(BitTorrent)
• Streaming (KanKan)
• VoIP (Skype)

Application Layer 2-37

 P2P file distribution:
BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

Application Layer 2-38

P2P file distribution: BitTorrent

 peer joining torrent:

• has no chunks, but will
accumulate them over
time from other peers
• registers with tracker to
get list of peers, connects
to subset of peers
(“neighbors”)

 while downloading, peer uploads chunks to other

peers
 peer may change peers with whom it exchanges
chunks
 churn: peers may come and go
 once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent Application Layer 2-39
Overview of application layer and
protocols
2.1 principles of 2.5 P2P applications
network 2.6 video streaming
applications and content
2.2 Web and HTTP distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket
2.4 DNS programming
with UDP and
TCP

Application Layer 2-40

Socket programming
goal: learn how to build client/server
applications that communicate using sockets
socket: door between application process and
end-end-transport protocol

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-41

 Socket programming
Two socket types for two transport services:
• UDP: unreliable datagram
• TCP: reliable, byte stream-oriented

Application Example:
1.client reads a line of characters (data)
from its keyboard and sends data to
server
2.server receives the data and converts
characters to uppercase
3.server sends modified data to client
4.client receives modified data and
displays line on its screen Application Layer 2-42
Socket programming with
UDP
UDP: no “connection” between client &
server
 no handshaking before sending data
 sender explicitly attaches IP destination
address and port # to each packet
 receiver extracts sender IP address and port#
from received packet
UDP: transmitted data may be lost or
received out-of-order
Application viewpoint:
 UDP provides unreliable transfer of groups of
bytes (“datagrams”) between client and server

Application Layer 2-43

Client/server socket interaction:
UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket

write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket

Application 2-44
Socket programming with
TCP
client must contact server  when contacted by client,
 server process must first server TCP creates new
be running socket for server process
 server must have created to communicate with that
socket (door) that particular client
welcomes client’s contact • allows server to talk
with multiple clients
client contacts server by: • source port numbers
 Creating TCP socket, used to distinguish
specifying IP address, port clients (more in Chap 3)
number of server process
 when client creates
socket: client TCP application viewpoint:
establishes connection to
server TCP TCP provides reliable, in-order
byte-stream transfer (“pipe”)
between client and server

Application Layer 2-45

Client/server socket interaction:
TCP
server (running on hostid) client
create socket,
port=x, for incoming
request:
serverSocket = socket()

wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket

Application Layer 2-46

 Chapter Outline
• Overview of application layer and
protocols
• The role of middleware
 Remote Procedure Calls (RPC)
 Web services
• Database-driven web applications
• Enterprise web based applications
Middleware
 Role of Middleware (MW)
In some early research systems: MW tried to
provide the illusion that a collection of separate
machines was a single computer.
– E.g. NOW project: GLUNIX middleware
Today:
– clustering software allows independent computers to
work together closely
– MW also supports seamless access to remote services.
 Role of Middleware (MW)
▪ provide high-level abstractions of
complex networking interactions
▪ let the programmer concentrate on
programming the business logic.
▪ enable location transparency
▪ free from specifics of
– communication protocols
– operating systems and
communication hardware
▪ interoperability
 Role of Middleware (MW)
The basic idea behind network
abstractions is to replace the local (server)
and remote (client) end by stubs.
This makes it possible for both client and
server to strictly use local calling
conventions and thereby be unaware of
calling a remote implementation or being
called remotely.
To accomplish this the client call is
handled by a client stub (proxy) that
marshals the parameters and sends them
to the remote end where another stub
receives the parameters, unmarshals and
calls the true server.
Middleware layers

Applications

RMI, RPC and events

Middleware
Request reply protocol layers

External data representation

Operating System
 Marshalling/Unmarshalling
Values must cross the network
Machine formats differ
– Integer byte order
• Little-endian or big-endian
– Floating point format
• IEEE 754 or not

The marshaling and un-marshaling actions are responsible for

converting data values from their local representation to a network
format and on to the remote representation. Format differences
like byte ordering and number representations are bridged this way
 Middleware Technologies Examples
CORBA (Common Object Request Broker
Architecture)
DCOM (Distributed Component Object
Management) – being replaced by .net
Sun’s ONC RPC (Remote Procedure Call)
RMI (Remote Method Invocation)
Web Service (SOAP)
 Chapter Outline
• Overview of application layer and
protocols
• The role of middleware
 Remote Procedure Calls (RPC)
 Web services
• Database-driven web applications
• Enterprise web based applications
 Remote Procedure Call
• Remote Procedure Call (RPC) is a
protocol that allows programs to call
procedures located on other machines.
• RPC uses the client/server model. The
requesting program is a client and the
service-providing program is the server.
• The client stub acts as a proxy for the
remote procedure.
• The server stub acts as a correspondent
to the client stub.
 RPC: The basic mechanism
Client process Server process 1. Client calls a local procedure
on the client stub
Client Server
routines routines 2. The client stub acts as a proxy
1 5 and marshalls the call and the
args.
Client Server
stub stub
3. The client stub send this to the
2 4
RPC RPC remote system (via TCP/UDP)
runtime runtime
4. The server stub unmarshalls
the call and args from the
Process Process
kernel kernel client
3 6
5. The server stub calls the actual
Network Network procedure on the server
routines routines

6. The server stub marshalls the

Source: R. Stevens, Unix Network Programming reply and sends it back to the
(IPC) Vol 2, 1998 client
 Chapter Outline
• Overview of application layer and
protocols
• The role of middleware
 Remote Procedure Calls (RPC)
 Web services
• Database-driven web applications
• Enterprise web based applications
 Web Service
A web service is a network accessible
interface to application functionality, built
using standard Internet technologies.
Clients of web services do NOT need to
know how it is implemented.
XML or JSON is used to encode all
communications to a web service.
Web services are built on top of open
standards such as TCP/IP, HTTP, Java,
HTML, and XML.
 Web Services (Why?)
Most middleware has been designed for
intra-enterprise
Inter-enterprise adds at least two
challenges
– Firewalls ( & inter-enterprise security in
general)
– Different middleware may be used at the two
ends
As well as different operating system,
languages, etc
 Web Services
Aims to address both of these issues
– Its protocol is layered on HTTP
So it can flow through a firewall
However this “cheat” raises security
and other concerns,
– It uses XML or JSON to format messages
So both sides can accept this as a
“neutral”
formatting approach
 Web Service Architecture
A Web Services architecture requires
three fundamental operations:
– publish, find, and bind.
Service providers publish services to a
service broker.
Service requesters find required services
using a service broker and bind to them.
Web Service Architecture

Find
Publish

Bind
 Web Services
Web Services would not replace existing
middleware such as
– CORBA
– J2EE
– MOM, EAI etc

Web Services are “integration

middleware” and not “platform
middleware”
Web Services – relationship to
other middleware
Use Web Services
– to integrate between different enterprises
– and to integrate between different “islands”
inside an enterprise
 Web Services Benefits
Promotes interoperability by minimizing the
requirements for shared understanding
– By limiting requirements for interoperability
allows platform and language independent
Enables just-in-time integration
– bound dynamically at runtime
Reduces complexity by encapsulation
– Coping with complexity, Flexibility and scalability,
Extensibility.
Enables interoperability of legacy
applications
– allowing legacy applications to be wrapped and
exposed as services
 Chapter Outline
• Overview of application layer and
protocols
• The role of middleware
 Remote Procedure Calls (RPC)
 Web services
• Database-driven web applications
• Enterprise web based applications
 Data Driven Web
Application
 Data-driven applications operate on a diverse
set of data (spatial, documents, sensor,
transactional, etc.) pulled from multiple
different sources, often in real-time and
create value from that data.

 Usage
– Make real-time recommendations to customers
(machine learning)
– Detect fraudulent transactions (machine learning)
– Identify influencers in a community and target
them with specific promotions. (Graph analytics )
– Keep track of deliveries using spatial data (GPS,
Remote Sensing)
 Enterprise web based
applications
 Enterprises are leveraging the benefits of web
application advantages in running business.
 These enterprises build many business systems
commonly known as Enterprise Web Application.
 Enterprise web applications allow companies to
handle internal and external needs and
operations.
 Examples include billing systems, customer
relationship management systems and supplier
relationship management systems.
 Enterprises often have so many different software
applications running simultaneously to improve
functionality, efficiency and production.
 Enterprise web based
applications
 Enterprise application integration (EAI) is a crucial
to ensure smooth communication between
applications and systems.
 EAI method can be categorize into TWO methods
– Point-to-Point
• the communication between a client and a service is
via a
point-to-point channel, and data exchange is done in
a
synchronous, request-response interaction.
• Works well when the entities are
relatively few and the interactions
are simple.
• Becomes increasingly complex when
there are many entities, and one
 Enterprise web based
applications
 EAI method can be categorize into TWO methods
– Middleware
• mediates the interaction between the heterogeneous
components, and ensures the reliability and
persistence of the messages.
• Free up the publishers from handling the tedious
work, and greatly simplifies the implementation and
logic of
service providers.
 References
James Kurose and Keith Ross, "Comptuer
Networking - A Top-Down Approach", Fifth
Edition, Chapter 2
Enterprise Software Architecture and
Design: Entities, Services, and Resources,
First Edition. Dominic Duggan. © 2012
John Wiley & Sons, Inc. Published 2012 by
John Wiley & Sons, Inc.
 References
The Future is Data-Driven. Retrieved from
https://blogs.oracle.com/database/data-dri
ven-apps
A Consumer Review-Driven Recommender
Service for Web E-CommerK. Lin, C. Shen,
T. Chang and T. Chang, "A Consumer
Review-Driven Recommender Service for
Web E-Commerce," 2017 IEEE 10th
Conference on Service-Oriented
Computing and Applications (SOCA), 2017,
pp. 206-210, doi: 10.1109/SOCA.2017.35.
Ji, Xiaogang. (2009). A Web-Based
Enterprise Application Integration Solution.
135 - 138. 10.1109/ICCSIT.2009.5234730.