The Application Layer
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Application Layer

on

  • 1,074 views

 

Statistics

Views

Total Views
1,074
Views on SlideShare
1,074
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Application Layer Presentation Transcript

  • 1. Web 2.1 and Rich Internet Applications Introduction Dr Suthikshn Kumar
  • 2. Course Content
    • Background
    • Client Side Technologies
    • Overview of XML
    • Web Services
    • Building Rich Internet Applications with AJAX
    • Building Rich Internet Applications with Flex-1
    • Flex-II
    • Building Advanced Web 2.0 Applications
  • 3. Background
    • What is Web 2.0?
    • Folsonomies and Web 2.0
    • Software as a Service ( SaaS) and Web 2.0
    • Convergence
    • Iterative Development
    • Rich User Experience
    • Multiple Delivery Channels
    • Social Networking
    • ( 3 hours)
  • 4. Client Side Technologies
    • Web browsers and Web Servers
    • URL, MIME, HTTP, XHTML, Plugins and Filters
    • CSS
    • Javascripts, General Syntactic characteristics, primitives, operations and Expressions, Control statements, Simple Examples
    • DOM, Events and Event handling, DOM2 event model
    • ( 6 Hours)
  • 5. XML
    • Basics, syntax,
    • XML Schemas
    • Document Type Definitions
    • Displaying XML Documents
    • CSS, XSLT
    • XML Parsors
    • ( 3 Hours)
  • 6. Web services
    • SOAP
    • RPC Style SOAP
    • Document style SOAP
    • WSDL
    • REST Services
    • JSON Format
    • JSON syntax
    • JSON versus XML
    • ( 4 hours)
  • 7. AJAX
    • AJAX Principles
    • Technologies behind AJAX
    • Dynamic web applications through Hidden frames for both GET and POST methods
    • IFrames
    • Asynchronous communication and AJAX application model
    • XMLHTTP Object
    • Cache control
    • AJAX Patterns: Predictive fetch patterns, submission throttling pattern, periodic refresh, multi stage download, fall back patterns
    • ( 10 Hours)
  • 8. Flex-I and Flex-II
    • Flash player
    • Flex Framework
    • MXML and ActionScript
    • Flex and Flash Authoring
    • Actionscript 3.0
    • Language Syntax: Objects, classes, packages and namespaces, operators, functions, conditional and looping, classes, interfaces, inheritance
    • Working with XML
    • ( 18 Hours)
  • 9. Advanced Web 2.0 Applications
    • Definition of mashup applications
    • Mashup techniques
    • Building a simple mashup application with AJAX
    • Remote data communication
    • Strategies for data communication
    • Simple HTTP Services
    • URL loaded in Flex
    • Example: Building an RSS reader with AJAX, Building an RSS reader with Flex
    • ( 8 Hours)
  • 10. Text Books
    • Programming the World Wide Web, by Robert Sebesta, ( Chapters 1-5, Chap 8), 3 rd Edition
    • Professional AJAX, Nicholas C Zakas, ( Chap 1-3, Chap 6, Chap 7)
    • Programming Flex 2, Chafic Kazoun, ( Chap 1, 3-7, 12, 16)
    • Amazon.com Mashups, Francis Shanahan, ( Chap 1 and Chap 6)
  • 11. Reference Books
    • Web enabled Commercial Application using HTML, DHTML, Javascript, Perl, CGI, Ivan Bayross
    • Essential Actionscript 3.0, Colin Moock
    • Ajax Bible, Steven Holzner
    • A Web 2.0 Primer Pragmatic Ajax, Justin Gehland
  • 12. Impact of World Wide Web
    • Origin
    • History of Computers, Evolution from Dynosaurs to human analogy
    • Tim Berners Lee, 1990
    • W3C
    • Sun Microsystems and Java
    • Open Source, Commercial Software
    • Standards
    • Dot Com burst
  • 13. Famous websites
    • Google
    • Amazon
    • CNN
    • Wikipedia
    • YouTube
    • Facebook
    • Hotmail, Yahoo
    • Napster
    • Auction
  • 14. Uses of Web
    • News
    • Email
    • Photo, video, audio, Maps
    • Online Shopping
    • Online Banking
    • Online Education and Examination
    • Searching
    • Collaboration
    • Information
    • Games
    • Medical and Health
    • Applications: Calender, Accounting, etc
  • 15. What is Web 2.0 ?
    • What is Web 1.0?
    • Before 2000
    • Website were well insulated entities that executed entirely within the browser and well within their own sphere of influence.
    • Users were important but no one would dare venture so far as to suggest that users specify what they wanted.
    • After 2000
    • Web 2.0 like art, has no real definition.
  • 16. Folksonomies
    • The term folksonomy refers to the process whereby a group of people collaborate to organize information using an impromptu vocabulary.
    • A common example in the corporate world is team building excercises, whereby a group of individuals rearrange flash cards on the floor or stickers on a white board. By getting a large group of people’s input, you have a higher probability of getting an appropriate classification of the information in question.
  • 17. How do Folksonomies apply to web 2.0?
    • In the web 2.0, there is a huge amount of information and it’s updated constantly.
    • It would be naïve to think that any one company could categorize that information so accurately that classification would make sense to everyone.
    • Who better to categorize data than the people closest to it?
    • For example Amazon allows users to tag products with key words. Over time, this will evolve into its own folksonomy where the users are adding value for other users simply by using amazon site.
  • 18. Software as a Service
    • Web 2.0 is about exposing a rich functionality set and much more data.
    • The data is generally accessible to both humans and machines, leading to more automation and derived applications than ever before.
    • The Web 2.0 world, companies are seeing more and more value in offering functionality in reusable and interoperable channels such as web services.
    • These channels are then handed over to the user for them to do with as they see fit.
    • Web 2.0 puts more trust in the user than ever before.
  • 19. More
    • Data is the King
    • Convergence
    • Iterative Development
    • Rich Browser Experience
    • Multiple Delivery channels
    • Social Networking
    • Rise of the Individual Developer
    • Amazon and Web 2.0
  • 20. Network applications: some jargon
    • Process: program running within a host.
    • within same host, two processes communicate using interprocess communication (defined by OS).
    • processes running in different hosts communicate with an application-layer protocol
    • user agent: interfaces with user “above” and network “below”.
    • implements user interface & application-level protocol
      • Web: browser
      • E-mail: mail reader
      • streaming audio/video: media player
  • 21. Applications and application-layer protocols
    • Application: communicating, distributed processes
      • e.g., e-mail, Web, P2P file sharing, instant messaging
      • running in end systems (hosts)
      • exchange messages to implement application
    • Application-layer protocols
      • one “piece” of an app
      • define messages exchanged by apps and actions taken
      • use communication services provided by lower layer protocols (TCP, UDP)
    application transport network data link physical application transport network data link physical application transport network data link physical
  • 22. App-layer protocol defines
    • Types of messages exchanged, eg, request & response messages
    • Syntax of message types: what fields in messages & how fields are delineated
    • Semantics of the fields, ie, meaning of information in fields
    • Rules for when and how processes send & respond to messages
    • Public-domain protocols:
    • defined in RFCs
    • allows for interoperability
    • eg, HTTP, SMTP
    • Proprietary protocols:
    • eg, KaZaA
  • 23. Client-server paradigm
    • Typical network app has two pieces: client and server
    • Client:
    • initiates contact with server (“speaks first”)
    • typically requests service from server,
    • Web: client implemented in browser; e-mail: in mail reader
    • Server:
    • provides requested service to client
    • e.g., Web server sends requested Web page, mail server delivers e-mail
    application transport network data link physical application transport network data link physical request reply
  • 24. Processes communicating across network
    • process sends/receives messages to/from its socket
    • socket analogous to door
      • sending process shoves message out door
      • sending process assumes transport infrastructure on other side of door which brings message to socket at receiving process
    Internet controlled by OS controlled by app developer
    • API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later)
    process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server
  • 25. Addressing processes:
    • For a process to receive messages, it must have an identifier
    • Every host has a unique 32-bit IP address
    • Q: does the IP address of the host on which the process runs suffice for identifying the process?
    • Answer: No, many processes can be running on same host
    • Identifier includes both the IP address and port numbers associated with the process on the host.
    • Example port numbers:
      • HTTP server: 80
      • Mail server: 25
    • More on this later
  • 26. What transport service does an app need?
    • Data loss
    • some apps (e.g., audio) can tolerate some loss
    • other apps (e.g., file transfer, telnet) require 100% reliable data transfer
    • Timing
    • some apps (e.g., Internet telephony, interactive games) require low delay to be “effective”
    • Bandwidth
    • some apps (e.g., multimedia) require minimum amount of bandwidth to be “effective”
    • other apps (“elastic apps”) make use of whatever bandwidth they get
  • 27. Transport service requirements of common apps Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Time Sensitive no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no
  • 28. Internet transport protocols services
    • TCP service:
    • connection-oriented: setup required between client and server processes
    • reliable transport between sending and receiving process
    • flow control: sender won’t overwhelm receiver
    • congestion control: throttle sender when network overloaded
    • does not provide: timing, minimum bandwidth guarantees
    • UDP service:
    • unreliable data transfer between sending and receiving process
    • does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee
    • Q: why bother? Why is there a UDP?
  • 29. Internet apps: application, transport protocols Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Dialpad) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP
  • 30. Domain Name System
    • Sending email to Ip address such as [email_address] complicates the matter:
      • Every time tana changes her machine, her email id has to change
      • Numbers complicate the matter
    • Hence ASCII names were introduced i.e., [email_address]
    • Since network only understands the numerical addresses, DNS was introduced to convert ASCII strings to network addresses.
  • 31. DNS
    • In early days of ARPANET, there was simply a file, hosts.txt, that listed all the hosts and IP addresses. For a network of few hundred machines, this approach worked very well.
    • However, when thousands of PCs and computers were connected to net, a new approach was needed.
    • The DNS was invented to solve this problem
    • DNS is a hierarchical, domain based naming scheme and a distributed database system.
    • DNS is used for mapping host names and email destinations to IP addresses.
  • 32. DNS: Domain Name System
    • People: many identifiers:
      • SSN, name, passport #
    • Internet hosts, routers:
      • IP address (32 bit) - used for addressing datagrams
      • “ name”, e.g., gaia.cs.umass.edu - used by humans
    • Q: map between IP addresses and name ?
    • . The DNS Name Space
    • . Resource Records
    • . Name Servers
    • Domain Name System:
    • distributed database implemented in hierarchy of many name servers
    • application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation)
      • note: core Internet function, implemented as application-layer protocol
      • complexity at network’s “edge”
  • 33. DNS Name Space
    • Managing a large and constantly changing set of names is a nontrivial task.
    • In postal system, name management is done by requiring letters to specify: country, state, city, street address, house number.
    • Thus there is no confusion between Marvin anderson on Main st. in white palms in NY and Marvin Anderson on Main St. in Austin Texas.
    • DNS works the same way.
  • 34. The DNS Name Space
    • The internet is divided into over 200 top level domains.
    • Each domain covers many hosts.
    • Each domain is partitioned into sub domains and these are further partitioned etc.
    • A portion of the Internet domain name space.
  • 35. DNS name servers
    • no server has all name-to-IP address mappings
    • local name servers:
      • each ISP, company has local (default) name server
      • host DNS query first goes to local name server
    • authoritative name server:
      • for a host: stores that host’s IP address, name
      • can perform name/address translation for that host’s name
    • Why not centralize DNS?
    • single point of failure
    • traffic volume
    • distant centralized database
    • maintenance
    • doesn’t scale!
  • 36. DNS: Root name servers
    • contacted by local name server that can not resolve name
    • root name server:
      • contacts authoritative name server if name mapping not known
      • gets mapping
      • returns mapping to local name server
    13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA
  • 37. Name Servers
    • Part of the DNS name space showing the division into zones.
  • 38. Name Servers (2)
    • Resolver on flits.cs.vu.nl wants to know the IP address of the host linda.cs.yale.edu
    • How a resolver looks up a remote name in eight steps.
    • Step1: flits.cs.vu.nl sends query to local name server cs.vu.nl
    • Step2: Local name server sends a UDP packet to the server edu-server.net
    • Step3: edu-server.net queries the name server yale.edu
    • Step4: yale.edu forwards the request to cs.yale.edu which has the authoritative resource records.
    • Step5-8: The resource record requested works its way back
    • This query method is also known as Recursive Query
  • 39. Simple DNS example
    • host surf.eurecom.fr wants IP address of gaia.cs.umass.edu
    • 1. contacts its local DNS server, dns.eurecom.fr
    • 2. dns.eurecom.fr contacts root name server, if necessary
    • 3. root name server contacts authoritative name server, dns.umass.edu, if necessary
    requesting host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu 1 2 3 4 5 6 local name server dns.eurecom.fr
  • 40. DNS example
    • Root name server:
    • may not know authoritative name server
    • may know intermediate name server: who to contact to find authoritative name server
    requesting host surf.eurecom.fr gaia.cs.umass.edu root name server 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu 7 8 local name server dns.eurecom.fr intermediate name server dns.umass.edu
  • 41. DNS: iterated queries
    • recursive query:
    • puts burden of name resolution on contacted name server
    • heavy load?
    • iterated query:
    • contacted server replies with name of server to contact
    • “ I don’t know this name, but ask this server”
    requesting host surf.eurecom.fr gaia.cs.umass.edu root name server 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu 7 8 iterated query local name server dns.eurecom.fr intermediate name server dns.umass.edu
  • 42. DNS: caching and updating records
    • once (any) name server learns mapping, it caches mapping
      • cache entries timeout (disappear) after some time
    • update/notify mechanisms under design by IETF
      • RFC 2136
      • http://www.ietf.org/html.charters/dnsind-charter.html
  • 43. DNS Resource records
    • Every domain can have a set of resource records associated with it.
    • For single host, the most common resource record is its IP Address.
    • When a resolver gives a domain name to the DNS, it gets back the RRs associated with that name
    • Type=NS
      • name is domain (e.g. foo.com)
      • value is IP address of authoritative name server for this domain
    • Type=A
      • name is hostname
      • value is IP address
    • Type=CNAME
      • name is alias name for some “cannonical” (the real) name
      • www.ibm.com is really
      • servereast.backup2.ibm.com
      • value is cannonical name
    • Type=MX
      • value is name of mailserver associated with name
    RR is five tuple RR format: (Domain_name, Time_to_live, Class, Type, Value)
  • 44. Resource Record
    • Domain name : tells the domain to which this record applies.
    • Time_to_live: field gives an indication of how stable the record is. Information that is highly stable is assigned large value such as 86400. Information that is highly volatile is assigned a smaller value as 60.
    • Class: field is always IN for internet information. For non-internet information, other codes can be used.
    • Type: field tells what kind of record this is.
  • 45. Resource Records
    • The principal DNS resource records types.
  • 46. Resource Records (2)
    • A portion of a possible DNS database for cs.vu.nl.
  • 47. DNS protocol, messages
    • DNS protocol : query and reply messages, both with same message format
    • msg header
    • identification: 16 bit # for query, reply to query uses same #
    • flags:
      • query or reply
      • recursion desired
      • recursion available
      • reply is authoritative
  • 48. DNS protocol, messages Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used
  • 49. The World Wide Web
    • Architectural Overview
    • Static Web Documents
    • Dynamic Web Documents
    • HTTP – The HyperText Transfer Protocol
    • Performance Ehnancements
    • The Wireless Web
  • 50. Architectural Overview
    • (a) A Web page (b) The page reached by clicking on Department of Animal Psychology .
  • 51. Architectural Overview (2)
    • The parts of the Web model.