Please wait, while our marmots are preparing the hot chocolate…
# @chunk: chunks/title.md # @chunk: chunks/objectives.md ## Part 2: Application Layer{overview} @SVG: media/stack-index.svg 100px 400px {svg floatright app unapp} - Application layer - high level of abstraction - « client » of the host to host network - interacts with the transport layer //
- Part 2{slide} - application layer and protocols - interaction with the transport layer - design of protocols // by studying existing protocols - programming connected application (socket) // API ## Part 2: Application Layer{#plan overview} @SVG: media/stack-index.svg 100px 400px {svg floatright app margin-left-minus-100} - Goal{shaded} - protocols: general principles and existing protocols - sockets: programming and services from the transport layer - Overview - Principles of distributed applications {it1} // and interactions with the transport layer - HTTP and the web {it2} - FTP: file transfer {it3} - Electronic mail {it4} - DNS: name resolution and more {it5} - P2P Applications (peer to peer) {it6} - Network programming: using sockets {it7} # @copy:#plan # @copy:#plan: %+class:inred: .it1 # Principles of Distributed Applications {no-print} ## Examples of Distributed Applications - e-mail{col1} - social networks{col2} - web{col1} - P2P file sharing{col2} - instant messaging {col1} - remote connections {col2} - multiplayer games {col1} - telephone{col2} - video and audio streaming {col1} - real time video-conferencing{col2} - …{col2} ## Design of Distributed Applications @SVG: media/part2/internet-app-to-app.svg 400px 500px {svg floatright} - Writing programs - executed on different hosts - communicating through the network - @anim: #mask-core + #mask-border | #stacks | #arrows - Network abstraction and separation{slide} - the application ignores the numerous details - the network core does not execute the application - Canonical types of architectures{slide} - client-server - P2P (peer to peer) ## Architectures for Distributed Applications @SVG: media/part2/internet-client-server-p2p.svg 400px 500px {svg floatright} - Client-Server{cs} - Server - always on - fixed (IP) address - server farms - Clients - intermittent comm. - changing address - comm. only
with the server - @anim:.svg + #mask-core + #mask-border | #arrowsclientserver + .cs | -#mask-border + -#arrowsclientserver + #mask-border2 | .p2p + #arrowsp2p - P2P (peer to peer) {p2p} - host = both client and server - no central server - complicated, dynamic management - better scalability ## Network Abstraction: interprocess comm. - Process - program running on a host - exchanging messages over the network - server process{slide} - waiting to be contacted - client process {slide} - contacting a server - P2P: client and server at the same time{slide} - Inter-process communications(IPC) {slide} - alternative to the network - works only on a single host // api dédiées, mémoire partagée ## Network Abstraction: socket - socket - used by a process (application) - interface to the rest of the network stack - interface to another (remote) process - @anim: .svg | #stack1 + #stack2 | #cloudconnect | #process1 + #process2 | %viewbox:#zsocket | #threed1 + #socket1 | #threed2 + #socket2 + %viewbox:#zpage | #cable @SVG: media/part2/socket.svg 800px 300px {svg} ## Network Abstraction:
process identification - Address of an host // "network" layer - IP address: 32 bits - example: 78.109.84.114 - but: there could be multiple processes on a host - Process identifier {slide} - address of the host - port number - example: 80 - ⇒ 78.109.84.114:80 ## Protocols from the Application Layer // what do we have in an application protocol (as in all protocols) - Types of messages{slide} - initialization, request, response, … - Syntax and format of messages{slide} - structure of messages - fields and their size - encoding, separators, … - Semantic of messages{slide} - meaning of the different message types - interpretation of the fields - Processing rules {slide} - how to answer the message? - when to answer? - Open protocols (HTTP, ...) vs proprietary protocols (Skype){slide} // inseparability, standard etc ## What are the advantages of open protocols?
… and of proprietary protocols?{question no-print} ## Services from the Transport Layer
(from the application point of view) {libyli} @SVG: media/stack-index.svg 100px 400px {svg floatright app margin-left-minus-100} - Transport integrity - guaranteed reception of all bits sent - Latency (delay) - reception of messages after a small time interval - guarantee on a maximum delay - Throughput (bandwidth) - guarantee on the average data transfer rate - guarantee on a (minimal) constant rate - Security - encryption, privacy protection - integrity (non-corruption) ## How sensitive to these aspects are the following application?{question bottom} - Aspects: integrity, latency, throughput, security - Applications - file transfer, e-mail, web browsing, - real-time audio/video, audio/video streaming, - multiplayer games, instant messaging ## Options for Transport with Internet // not any network? - Transport with TCP {col1 slide} - connection oriented (stream) - transfer integrity - from socket to socket - flow control{slide} - prevent “spam” - congestion control{slide} - adaptation to network load - missing services{slide} - guaranteed latency - guaranteed rate - security - UDP {col2 slide} - packet oriented (datagram) - transport not guaranteed - missing services{slide} - transfer integrity - flow control - congestion control - guaranteed latency - guaranteed rate - security - Question: so, why UDP?{col12 slide} ## Internet Apps and Transfer Protocols
ApplicationApplication ProtocolsTransfer Protocols
e-mail SMTP (RFC2821) TCP
Web Browsing HTTP (RFC2616) TCP
remote access (terminal) Telnet (RFC854) TCP
remote access (terminal) SSH (RFC4251)
multiple RFC actually (the others too)
TCP
file transfer FTP (RFC959) TCP
Streaming HTTP, RTP (RFC1889) TCP, UDP
Voice over IP SIP, RTP, prop. TCP or UDP
## Absence of Security in TCP and UDP {libyli} - TCP and UDP do not propose encryption - data sent “as is”, including passwords etc - possibility for any router to read these - TLS (Transport Layer Security) - evolution/renaming of SSL (Secure Sockets Layer) - systematic encryption before sending through TCP - authentication/identification of hosts (with “certificates”) - Notes about TLS - TLS is an application layer protocol - TLS is just a software library // with an API close to plain sockets - the `ssh` command allows users to create secured tunnels

/ will be replaced by the authorwill be replaced by the title