Networked
Applications
Chapter 11
Panko’s
Business Data Networks and Telecommunications, 6th edition
Copyright 2007 Prentice-Hall
May only be used by adopters of the book
Application
Architectures
Application Architectures
• An application architecture is the design
decision about which network host or hosts to
use to do the processing work in an
application
3
Figure 11-1: Simple Terminal-Host System
All Processing is done on the host.
Host gets overloaded: slow response.
Extensive network traffic: expensive.
Dumb
Terminal
Modem
Dumb
Terminal
Telephone
Network
Modem
Host
4
Client/Server Computing
• The client does at least some of the work
• Made possible by growing client processing power
(PCs)
• Two versions
– File server program access
– Request/response processing
5
Figure 11-2: Client/Server Computing
File Server Program Access
1.
Program
Stored on
File Server
File Server
2.
Program
Downloaded to
Client PC
When Called
3.
Program
Executed on
Client PC Client PC!
Only useful for small programs (e-mail, word processing, etc.)
Because clients do not get very large
6
Figure 11-2: Client/Server Computing
Client/Server Processing with Request-Response Cycle
Request Message
Client Program
Response Message
Does Light I/O and
Post-Download
Processing
Client PC
Server Program
Does Heavy
Database
and Other Heavy
Processing
Server
Highly scalable: Use larger server as number of clients increases
7
Figure 11-3: Web-Enabled Application (E-Mail)
HTTP Request Message
Client is Browser
Client PC
HTTP Response Message
Server Program
Form of client server processing
that uses browsers as clients
Almost all client PCs
now have browsers.
No need to install new software.
E-Mail Server
8
E-Mail
Figure 11-4: E-Mail
• Importance of E-Mail
Expanded
List
– Universal service on the Internet
– Attachments make e-mail a general file delivery
mechanism
– Messages with inappropriate content, viruses, worms,
spam, adware, spyware, and other abuses
10
Figure 11-5: E-Mail Standards
2.
SMTP
To Send
1.
SMTP
To Send
Sender’s Mail
Server
Sending
E-Mail
Client
Receiver’s Mail
Server
Simple Mail Transfer Protocol
(SMTP) is used to transmit mail
in real time to a user’s mail
server or between mail servers
Receiving
E-Mail
Client
Sender-initiated
11
Figure 11-5: E-Mail Standards
Sender’s Mail
Server
Sending E-Mail
Client
Receiver’s Mail
Server
POP or IMAP to download mail to
receiver when the receiver is next
capable of downloading mail.
POP or
IMAP
To Receive
Receiving
E-Mail
Client
Receiver-initiated
12
Figure 11-5: E-Mail Standards
Sender’s Mail
Server
Receiver’s Mail
Server
Message Body Format Standard
Sending
E-Mail
Client
Message
RFC 822 or 2822
HTML body
UNICODE
Receiving
E-Mail
Client
13
Figure 11-4: E-Mail
• E-Mail Standards
– Message body standards
• Receiver must understand sender’s message
• RFC 822 and RFC 2822 for all-text bodies
• HTML bodies with fancy text and graphics
• UNICODE for non-English language characters
14
Figure 11-6: Interactions in the Simple Mail
Transfer Protocol (SMTP)
Actor
SMTP Message
Comment
Client SMTP
Process
None
Connects to server
Via TCP
Server SMTP
Process
Client SMTP
Process
Server
When a TCP connection
220 Mail.Panko.Com Ready
is opened, the server
signals that is is ready.
Client asks to begin
HELO Voyager.cba.Hawaii.edu Sending a message.
Gives own identity.
Server signals that it
250 Mail.Panko.Com
Is ready to begin
Receiving a message.
15
Figure 11-6: Interactions in the Simple Mail
Transfer Protocol (SMTP)
Actor
SMTP Message
Comment
Client
MAIL FROM: Bob@
voyager.cba.hawaii.edu
Client identifies the sender
(mail author, not SMTP
process).
Server
250 OK
Accepts author. However,
May reject mail from others.
Client
RCPT TO: Ray@Panko.com
Identifies first mail recipient.
Server
250 OK
Accepts first recipient
16
Figure 11-6: Interactions in the Simple Mail
Transfer Protocol (SMTP)
Actor
SMTP Message
Comment
Client
RCPT TO:Lee@Panko.com
Identifies second mail
Recipient.
Server
550 No such user here
Does not accept second
Recipient. However will
deliver to first recipient.
Client
DATA
Message will follow.
Server
354 Start mail input; end with
<CRLF>.<CRLF>
Gives permission to send
message.
17
Figure 11-6: Interactions in the Simple Mail
Transfer Protocol (SMTP)
Actor
SMTP Message
Comment
Client
When in the course …
The message. Multiple lines
Of text. Ends with line
Containing only a single
Period: <CRLF>.<CRLF>
Server
250 OK
Server accepts message.
Client
QUIT
Requests termination of
Session.
Server
221 Mail.Panko.Com Service
Closing transmission channel
End of transmission.
Server
None
Closes TCP connection.
18
Sample SMTP Exchange
• S: HELO pc-ycc
R: 250 euler.im.ncnu.edu.tw Hello …, pleased
to meet you
• S: MAIL FROM: Smith@Alpha.ARPA
R: 250 OK
• S: RCPT TO: Jones@Beta.ARPA
R: 250 OK
• S: RCPT TO: Green@Beta.ARPA
R: 550 No such user here
• S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah….
S:…etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK
• S: QUIT
19
POP3
Post Office Protocol - Version 3
• RFC 1939 / Std 53
• To retrieve emails from server (POP3 server)
• Three states
– Authorization State
– Transaction State
– Update State
20
POP3 Commands
•
Authorization State
– USER username
– PASS password
•
Update State
– QUIT
– APOP name digest
•
Transaction State
– STAT
– LIST [msgNo]
– RETR msgNo
– DELE msgNo
– NOOP
– RSET
– TOP msgNo line
– UIDL [msgNo]
21
S:
C:
S:
C:
S:
C:
S:
C:
S:
S:
S:
S:
C:
S:
S:
S:
C:
S:
C:
S:
+OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
USER mrose
+OK User name accepted, password please
PASS pwd999
+OK Mailbox open, 2 messages (320 octets)
STAT
+OK 2 320
LIST
+OK 2 messages (320 octets)
1 120
2 200
.
RETR 1
+OK 120 octets
<the POP3 server sends message 1>
.
DELE 1
+OK message 1 deleted
QUIT
+OK dewey POP3 server signing off (maildrop empty)
22
RFC 822
• Defines format for text messages via electronic
mail
• Used by SMTP as accepted mail format
• Specifies both envelope and contents
• Includes a variety of headers that can be included
in the message header lines
23
24
Received: By OpenMail Mailer;Thu, 15 Jun 2006 09:41:13 +0800 (CST)
From: "Yen-Cheng" <ycc123@ms6.hinet.net>
Reply-To: ycc123@ms6.hinet.net
Subject: A test mail for BDC 2006
Message-ID: <1150335673.27009.ycchen@ncnu.edu.tw>
To: "=?big5?B?MS2zryCr27/+IKbRrnY=?=" <ycchen@ncnu.edu.tw>
Cc: ycchen@im.ncnu.edu.tw
Date: Thu, 15 Jun 2006 09:41:13 +0800 (CST)
RFC 822/2822
MIME-Version: 1.0
Return-Path: ycc123@ms6.hinet.net
Disposition-Notification-To: "Yen-Cheng" <ycc123@ms6.hinet.net>
X-Priority: 1
X-MSMail-Priority: High
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: quoted-printable
Headers
Hi,
This=20mail=20is=20just=20to=20say=20hello.
So,=20Hello!
Fred=20Chen
25
--=3D=3DMailed=20via=20NCNU=20E-Mail=3D=3D--

26

27
Limitations of SMTP and RFC822
• Cannot transmit executables or binary files without
conversion into text through non-standard programs
(e.g. UUENCODE)
• Cannot transmit diacritical marks
• Transfers limited in size
• Gateways do not always map properly between EBCDIC
and ASCII
• Cannot handle non-text data in X.400 messages
• Not all SMTP implementations adhere completely to
RFC821 (tabs, truncation, etc)
28
MIME
(Multipurpose Internet Mail Extensions)
• Intended to resolve problems with SMTP and
RFC822
• Specifies five new header fields, providing info
about body of message
• Defines multiple content formats
• Defines encodings to enable conversion of any
type of content into transferable form
29
MIME
• Multipurpose Internet Mail Extensions (MIME)
– System for identifying format of a file.
• Used in e-mail attachments
• Used in HTTP downloads and other applications
– Examples (Top-Level Media Type/Specific Type)
• Text/Plain (plain ASCII text)
• Image/JPEG (JPEG graphic file)
• Octet/Stream (un-interpreted bytes for application)
• Application/Postscript (Postscript application data)
30
MIME Header Fields
• MIME-Version: Indicates compliance with RFCs 1521
and 1522
• Content-Type: Describes data in sufficient detail for
receiver to pick method for representation
• Content-Transfer-Encoding: Indicates type of
transformation used to represent content
• Content-ID: Used to uniquely identify MIME entities
• Content-Description: Plain text description for use
when object is not readable
31
MIME Content Types
• Seven major types: Text, Multipart, Message,
Image, Video, Audio, Application
• Fourteen subtypes
• Text provides only plain subtype, but a richtext
subtype is likely to be added
• Multipart indicates separate parts, such as text and
an attachment
• MIME types are used by web servers, as well
32
Content Types
• Text
– Plain
• Multipart
– Mixed, Parallel, Alternative, Digest
• Message
– RFC 822, Partial, External-body
• Image
– jpeg, gif
• Video
– mpeg
• Audio
– Basic
• Application
– Postscript, octet stream
33
multipart/mixed
...
From: "Yen-Cheng Chen" <ycchen@ncnu.edu.tw>
To: <ycchen@im.ncnu.edu.tw>
Subject: test mail!
Date: Wed, 22 May 2002 14:27:07 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0047_01C2019E.69F32C40“
Status:
This is a multi-part message in MIME format.
------=_NextPart_000_0047_01C2019E.69F32C40
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
Start of Body!
Yen-Cheng
------=_NextPart_000_0047_01C2019E.69F32C40
Content-Type: text/plain; name="a.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="a.txt“
This is the first and only one line of the file.
------=_NextPart_000_0047_01C2019E.69F32C40--
34
Content-Transfer-Encoding
• Reliable delivery across wide range of environments
• Content transfer encoding field
– Six values
– Three (7bit, 8bit, binary) no encoding done
• Provide info about nature of data
• Quoted-printable
– Data largely printable ASCII characters
– Non-printing characters represented by hex code
• Base64
– Maps arbitrary binary input onto printable output
• X-token
– Named nonstandard encoding
35
Quoted-printable
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: quoted-printable
一年=365天
=A4@=A6~=3D365=A4=D1
暨南大學
=BA[=ABn=A4j=BE=C7
A=B
A=3DB
36
Content-Transfer-Encoding
• Content-Transfer-Encoding: base64
24 bits
0 0
0 0
0 0
0 0
Radix-64
0~63  A~Za~z0~9+/
32 bits
37
HTML and HTTP
Figure 11-7: HTML and HTTP
Browser
1.
HTTP Request
Webserver
Application
2.
HTTP Response
Webserver
Client PC
HTML Document
39
Figure 11-8: Downloading a Complex Webpage
with Two Graphics Files
HTML Document
Browser
Client PC
Webserver
Application
Webserver
As
Displayed
2
Graphics
Files
Webpage Consists of Three Files
Rendered as a Single Page On-Screen
40
Figure 11-8: Downloading a Complex Webpage
with Two Graphics Files
1.
HTML Document
Browser
Client PC
As
Displayed
HTML Document
Webserver
Application
2
Graphics
Files
Webserver
Download Requires 3
HTTP Request-Response Cycles;
Downloads HTML Page First
It has Tags to Identify Other Files
41
Figure 11-8: Downloading a Complex Webpage
with Two Graphics Files
2.
Browser
Client PC
As
Displayed
3.
Webserver
Application
2
Graphics
Files
Webserver
Based on Tags in HTML Document,
Browser Requests Downloads of
Remaining Graphics or Other Files
Browser Renders Combined Webpage on Screen
42
Figure 11-8: Downloading a Complex Webpage
with Two Graphics Files
• Quiz: Your browser downloads a webpage with
three graphics images, a sound sequence, and a
Java applet. How many files will your browser have
to download?
43
HTTP Messages
• Requests
– Client to server
• Responses
– Server to client
• Request line
• Response line
• General header
• Request header
• Response header
• Entity header
• Entity body
44
HyperText Transfer Protocol (HTTP)
http://www.im.ncnu.edu.tw:80/~ycchen/
http://www.im.ncnu.edu.tw/~ycchen/www/test.cgi?var1=123&var2=value2
File Transfer Protocol (FTP)
ftp://ftp.ncnu.edu.tw/
ftp://ftp.ncnu.edu.tw/JavaDownload/Docs/
URL Examples
ftp://anonymous:guest@ftp.ncnu.edu.tw/
ftp://ycchen@www.im.ncnu.edu.tw/
Gopher Protocol (Gopher)
gopher://gopher.nsysu.edu.tw/11/traveler/train
Electronic Mail (Mailto)
mailto:username@ncnu.edu.tw
mailto:username@ncnu.edu.tw?subject=Hello!
Usenet News (News)
news:tw.bbs.rec.travel
news:*
Telnet to Remote Host (Telent)
telnet://bbs.ee.cycu.edu.tw/
telnet://guest@bbs.ncnu.edu.tw/
URL: Uniform Resource Locator
Host-Specific File Names (File)
file:///C|/My Documents/
46
15 sec,
at most 100 requests
47
48
49
50
Figure 11-9: Examples of HTTP Request
and Response Messages
• HTTP Request Message
– GET /panko/home.htm HTTP/1.1[CRLF]
– Host: voyager.cba.hawaii.edu[CRLF]
• Notes:
– CRLF: carriage return and line feed
• Two ASCII characters
• Start a new line
– Beyond the first line, each line is a field
• Variable name: value
51
Figure 11-9: Examples of HTTP
Request and Response Messages
• HTTP Response Message
– HTTP/1.1 200 OK[CRLF]
– Date: Tuesday, 20-JAN-2004 18:32:15 GMT[CRLF]
– Server: name of server software[CRLF]
– MIME-version: 1.0[CRLF]
– Content-type: text/plain[CRLF]
– [CRLF]
– File to be downloaded
52
Figure 11-9: Examples of HTTP Request
and Response Messages
• File to be Downloaded
– HTML documents are plain text files
• Only use keyboard characters
• Use the ASCII code to represent them
– Many other files are arbitrary strings of bytes
• Graphics files
• Sound files
• Etc.
• Come after the blank line following the response
header
53
MIME
New
Not in Book
• Multipurpose Internet Mail Extensions (MIME)
– System for identifying format of a file.
• Used in e-mail attachments
• Used in HTTP downloads and other applications
– Examples (Top-Level Media Type/Specific Type)
• Text/Plain (plain ASCII text)
• Image/JPEG (JPEG graphic file)
• Octet/Stream (un-interpreted bytes for application)
• Application/Postscript (Postscript application data)
54
MIME: .mht/.mhtml
New
Not in Book
• IE5 introduced the new 'Web Archive' format for
storing web pages, which have the extension
MHT.
• The 'Web Archive' saves a web page as a single
document complete with all images.
• The format is a standard mime/multipart e-mail
message.
• .mht  .eml
55
E-Commerce
Figure 11-10: Electronic Commerce Functions
Browser
Webserver
Application
E-Commerce
Server
Customer
PC
External
Bank
Internal
Warehouse
Database
57
Figure 11-10: EC Functions
• Webserver Functionality, Plus…
• E-Commerce functionality
– Online catalog
– Shopping cart
– Checkout, including payment
– Customer resource management (CRM)
– Links to External Systems
• Credit card number checking
• Bank settlement
58
Figure 11-10: EC Functions
• E-Commerce functionality
– Links to internal systems
• Accounting
• Pricing
• Warehousing (Product Availability)
• Shipment
• Etc.
59
Figure 11-11: Application Server (3-Tier
Architecture
Client PC
with
Browser
1.
Form
Webserver
Application
2.
Server
Data
Mainframe
Server of
External Company
Database
Server
60
Figure 11-11: Application Server (3-Tier
Architecture
Client PC
with
Browser
Webserver
3.
Mainframe
Query and
Application
Response
Server
Mainframe
Mainframe CICS and other matters (3)
Database
Server
Server of
External Company
61
Figure 11-11: Application Server (3-Tier
Architecture
Client PC
with
Browser
Webserver
Application
Server
4.
DB Server Mainframe
Query and
Response
5. External Query/
Response
Database Sever Interactions (4, 5)
Application program interfaces (API)
Both internal and external database hosts
Database
Server
Server of
External Company
62
Figure 11-12: E-Commerce Security
Subnet for
Internal Hosts
(Little or No Access
From Outside)
Ethernet
Switch
DMZ
Subnet
(Easy Access from Outside)
Customer
DMZ: Subnet for
Externally-Facing
Servers
Marketing
Client
Accounting
Server
E-Commerce
Server
63
Figure 11-12: E-Commerce Security
SSL/TLS
SSL/TLS provides
protection against
eavesdroppers
Customer
E-Commerce
Server
64
Software as a Service
(SAS)
Figure 11-13: Software as a Service (SAS)
Ordinary Webservice
HTTP Request
Browser
HTTP Response
Webserver
Application
Webserver
Client PC
HTML or Other Document
Ordinary webservice was created to download documents
66
Figure 11-13: Software as a Service (SAS)
SOAP
Request Message
(Parameters/
Calling
Properties)
Program
Client PC
Service
Object
SOAP
Response Message
Numerical Answer
Other
Computer
67
Figure 11-13: Software as a Service (SAS)
HTTP Request
Client PC
SOAPCapable
Browser
HTTP Response
SOAP Message
Using XML Syntax
Service
Object
Webserver
-Interface
Properties
Methods
SOA requests are sent to a service object via HTTP
They are sent as SOAP messages written in XML
68
Figure 11-14: Simple SOAP Request
and Response
• Simple Object Access Protocol (SOAP)
• Carried in HTTP request or response message
• Formatted using XML Syntax
– Similar to HTML syntax but
the sender and receiver can
create new tags that
they can then use in
transactions, such as
<price>$33</price>
HTTP Header
SOAP
Body
69
Figure 11-14: Simple SOAP Request and
Response
• Situation
– There is a pricing object that returns the price if another
object sends the part number, quantity, and shipping type
(rush, etc.) on an interface
– Objects can be on different computers
Request
(PartNum, Quantity, ShippingType)
Sending
Object
Pricing
Object
Response
(Price)
70
Figure 11-14: Simple SOAP Request and
Response
• SOAP Request Message
HTTP Request Header pointing to program
<?xml version=“1.0”>
<BODY>
<QuotePrice xmlns=“QuoteInterface”>
<PartNum>QA78d</PartNum>
<Quantity>47</Quantity>
<ShippingType>Rush</ShippingType>
</QuotePrice>
</BODY>
Note: xmlns specifies an XML namespace for the object
71
Figure 11-14: Simple SOAP Request and
Response
• SOAP Response Message
HTTP Response Header
<?xml version=“1.0”>
<BODY>
<QuotePrice xmlns=“QuoteInterface”>
<Price>$750.33</Price>
</QuotePrice>
</BODY>
72
Figure 11-15: Universal Description, Discovery,
and Integration (UDDI) Server for SAS
Client PC
UDDI Functions:
2.
SOAP Interaction
1.
Server with
UDDI
the Identified
Request for
Service Object
Information,
Response
Interaction Between
UDDI Servers
to Fulfill a Request
UDDI Server
White Pages
By name
Yellow Pages
By type
Green Pages
Details of how
to use,
payment, etc.
UDDI Server
73
Perspective on SAS
New: Not
In Book
• Benefits of SAS
– Offers a way to standardize interactions between
objects over the Internet
– Can make distributed computing far simpler once
Web services standards are fully developed
• Concerns
– High overhead (very chatty)
– Standards immaturity
– Security is embryonic
74
Peer-to-Peer
Computing
Figure 11-16: Traditional Client/Server
Application
Client PC
Client PC
Advantage:
Central Control
Client PC
Client PC
Client PC
Disadvantages:
Network Overload at Server
Underused Client Power
Central Control
Server Does Heavy Processing Work
76
Figure 11-17: Simple Peer-to-Peer (P2P)
Application
Request
Client PC
Response
Benefits:
End User Freedom
No Network Bottleneck at Serve
Uses Client Capacity Better
Client PC
Problems:
Transient Presence of Clients
Transient Client IP Addresses
Security (No Central Control)
77
P2P Applications
• Direct service, although most P2P systems use
facilitating servers for some of the work
Peer
Peer
Peer
Peer
Peer
Peer
78
Figure 11-18: Gnutella: Pure P2P with Viral
Networking
Gnutella
Client (ABC)
1. Init or
Search
Message
2.
Init or Search
Message
2. Init or
Search
Message
Gnutella
Client
(Carol)
3.
Init or Search
Message
Gnutella
Client (DEF)
3. Init or
Search
Message
3. Init or
Search
Message
4.
P2P File Download
HTTP Request-Response Gnutella
Cycle
Client (XYZ)
Gnutella
Client (GHI)
79
Figure 11-19: Napster
Napster
Index Server
1.
Uploads List
Of Available Files
When Connects
Client A
2.
Search Query
3.
Response
File List
List of
Available
Files
From All
Current Clients
Client B
4.
Large P2P
Download
Client C
80
Figure 11-20: Use of Servers in Instant Messaging
Pure P2P IM
Ongoing
Communication
Client PC A
Client PC B
In pure P2P IM, there are no servers.
The clients communicate directly.
Finding each other can be difficult because of DHCP.
81
Figure 11-20: Use of Servers in Instant Messaging
Use of a Presence Server
1.
Presence
Information
Client PC C
3.
Ongoing
Communication
2.
Presence
Information
Client PC D
Clients register with presence servers.
Presence servers notify other clients as appropriate.
Clients use this information to communicate directly.
82
Figure 11-20: Use of Servers in Instant Messaging
Use of a Relay Server
All Communication
Goes through the
Relay Server
Client PC E
Presence
Information
Client PC F
Relay servers route all IM messages.
This permits security filtering and other services.
It limits privacy because the relay server sees everything.
83
Figure 11-21: SETI@Home Client PC Processor
Sharing
1. I am idle. Give me work.
2. Here is work to do
3. I am busy now. Here are my results.
Idle Client PC
With SETI@home
Screen Saver Program
SETI@home
Server
No Interaction
Busy Client PC
With SETI@home
Screen Saver Program
84
Perspective on Application
Architectures
• Driven primarily by the evolution of client
processing power
• Terminal-Host: Client processing power was
uneconomical
• Client/Server: Client PCs could handle some of
the load
• P2P: Clients have rich power to do most things
85
Topics Covered
Topics Covered
• Application Architectures
– Terminal-host
– Client/server
• File server program access
• Client/server processing with request/response cycle
– Peer-to-peer (P2P)
– Evolution of architectures driven by growing desktop
computer power
87
Topics Covered
• E-Mail
– Sending: Simple Mail Transfer Protocol (SNMP)
– Retrieving: POP and IMAP
– Document format standards: RFC 822/2822, HTML, and
UNICODE
– Viruses, worms, and Trojan horses
• Where to do antivirus filtering?
– Spam
88
Topics Covered
• HTTP and HTML
– Webpages consist of an HTML document and multiple
graphics, etc. files
– Message transfer: HTTP
• Multiple downloads for the multiple files in a webpage
– MIME
89
Topics Covered
• E-Commerce
– E-Commerce : webservice with additional functionality
– Webserver interacts with customer browser
– Application server interacts with back-end databases,
passes webified response to the webserver for delivery
to the customer
– DMZ and SSL/TLS security
90
Topics Covered
• Software as a Service (SAS)
– Regular webservice: retrieve stored files
– SAS: use HTTP and extended HTML to handle programto-program interactions on different machines
– SOAP request message passes parameters to a service
object on another machine
– SOAP response message brings the reply
– SOAP messages are written in XML
91