Petros KAVASSALIS

Post on 25-Feb-2016

30 views 1 download

description

Computer Networks and Communications [Δίκτυα Υπολογιστών και Επικοινωνίες] Lectures 10-13: Back to applications… The e-mail app. Univ. of the Aegean Financial and Management Engineering Dpt. Petros KAVASSALIS. What you will learn in this course. - PowerPoint PPT Presentation

Transcript of Petros KAVASSALIS

1

Computer Networks and Communications

[Δίκτυα Υπολογιστών και Επικοινωνίες]Lectures 10-13: Back to applications… The

e-mail app.Univ. of the Aegean

Financial and Management Engineering Dpt

Petros KAVASSALIS

<pkavassalis@atlantis-group.gr> 2

What you will learn in this course

A set of fundamental concepts for understanding Data Networks and the Internet What is the Internet? Internet architecture and layers Internet applications and services New concepts in the evolution of the Internet The Internet goes Wireless…

Familiarization with the structure and organization of Digital Networks Business and Social Networks Electronic Markets and Online Feedback Mechanisms

<pkavassalis@atlantis-group.gr> 3

Who am I?

PhD in Economics and Management (Univ. Paris Dauphine & Ecole polytechnique)

Research experience Ecole polytechnique, Paris MIT Center of Technology Policy and Industrial Development, MIT

CTPID (MIT Internet Telecommunications Convergence Consortium)

Current positions Univ. of the Aegean (FME): Assoc. Professor RACTI: Director of ATLANTIS Group

<pkavassalis@atlantis-group.gr> 4

Communication tools

e-mail: pkavassalis [at] atlantis-group.gr Course web site: see fme website

<pkavassalis@atlantis-group.gr> 5

Course Textbook[http://books.google.gr/books?id=Pd-z64SJRBAC&dq=tanenbaum+networks&printsec=frontcover&source=bn&hl=el&ei=ml-dSfH9L4S2jAeJ5L3ZBQ&sa=X&oi=book_result&resnum=4&ct=result]

<pkavassalis@atlantis-group.gr> 7

Students evaluation

Class Participation (20%)

+ Assignments (20%)

+ Final Exam (60%)

Reminder (1): Overview of the Internet

Petros KAVASSALIS <petros@cfp.mit.edu> 8

The structure of the Internet is roughly hierarchical

Reminder (2): A network architecture

Petros KAVASSALIS <petros@cfp.mit.edu> 9

Reminder (3): TCP/IP in practice

Petros KAVASSALIS <petros@cfp.mit.edu> 10

Create a network app

Write programs that Run on (different) end systems Communicate over network Think about that: Server software

communicates with browser software

No need to write software for network-core devices Network-core devices do not run

user applications Applications on end systems

allows for rapid app development, propagation

Petros KAVASSALIS <petros@cfp.mit.edu>11

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

Application architectures

Client-server

Peer-to-peer (P2P)

Hybrid of client-server and P2P

Petros KAVASSALIS <petros@cfp.mit.edu> 12

Client-server

Server: Always-on host Permanent IP address Server farms for scaling

Clients: Communicate with server May be intermittently

connected May have dynamic IP

addresses Do not communicate directly

with each other

Petros KAVASSALIS <petros@cfp.mit.edu> 13

client/server

P2P

No always-on server Arbitrary end systems

directly communicate peers are intermittently

connected and change IP addresse **** Highly scalable but

difficult to manage

Petros KAVASSALIS <petros@cfp.mit.edu> 14

peer-peer

Hybrid

Skype voice-over-IP P2P application centralized server: finding address of remote party: client-client connection: direct (not through server)

Instant messaging chatting between two users is P2P centralized service: client presence detection/location

o user registers its IP address with central server when it comes online

o user contacts central server to find IP addresses of buddies

Petros KAVASSALIS <petros@cfp.mit.edu> 15

An Internet application example: e-mail

Most heavily used application on any network

Protocols Simple Mail Transfer Protocol (SMTP)

o TCP/IPo Delivery of simple text messages

Multi-purpose Internet Mail Extension (MIME)o Delivery of other types of datao Voice, images, video clips

Petros KAVASSALIS <petros@cfp.mit.edu> 16

SMTP

RFC 821 (please locate the document!) Not concerned with format of messages or data

Covered in RFC 822 (see later) SMTP uses info written on envelope of mail

Message header Does not look at contents

Message body Mail created by user agent program (mail client): Message consists of:

Header containing recipient’s address and other info Body containing user data

Messages queued and sent as input to SMTP sender program Typically a server process (daemon on UNIX)

Petros KAVASSALIS <petros@cfp.mit.edu> 17

Mail message content

Each queued message has: Message text

o RFC 822 header with message envelope and list of recipients

o Message body, composed by user A list of mail destinations

o Derived by user agent from headero May be listed in headero May require expansion of mailing listso May need replacement of mnemonic names with

mailbox names

Petros KAVASSALIS <petros@cfp.mit.edu> 18

Mail example

Date: Tue 19 May 2008 10:37:17 (EST)From: “Petros Kavassalis” <petros@cfp.mit.edu>Subject: Xronia PollaTo: el……@gmail.comCc: petros@cfp.mit.eduFollows the main text, delimited from the header by a blank line

Message viewed as having envelope and contents Envelope contains information required to transmit and deliver

message Message is sequence of lines of text

Petros KAVASSALIS <petros@cfp.mit.edu> 19

Mail structure

SMTP: protocol for exchanging email msgs

RFC 821+822: standard for text message format:

header lines, e.g., To: From: Subject:

body the “message”, ASCII characters

only

Petros KAVASSALIS <petros@cfp.mit.edu> 20

header

body

blankline

SMTP operation architecture

Petros KAVASSALIS <petros@cfp.mit.edu> 21

SMTP Sender

Takes message from queue Transmits to proper destination host

Via SMTP transaction Over one or more TCP connections to port 25

Host may have multiple senders active Host should be able to create receivers on demand When delivery complete, sender deletes destination from list

for that message When all destinations processed, message is deleted

Petros KAVASSALIS <petros@cfp.mit.edu> 22

Room for optimization

If message destined for multiple users on a given host It is sent only once = Delivery to users handled at destination host

If multiple messages ready for given host a single TCP connection can be used = Saves overhead of setting up and dropping connection

Petros KAVASSALIS <petros@cfp.mit.edu> 23

SMTP reliability

Used to transfer messages from sender to receiver over TCP connection

Attempts to provide reliable service No guarantee to recover lost messages No end to end acknowledgement to originator Error indication delivery not guaranteed Generally considered reliable

Petros KAVASSALIS <petros@cfp.mit.edu> 24

SMTP Receiver

Accepts arriving message Places in user mailbox or copies to outgoing queue for

forwarding Receiver must:

Verify local mail destinations Deal with errors

o Transmissiono Lack of disk space

Sender responsible for message until receiver confirm complete transfer Indicates mail has arrived at host, not user

Petros KAVASSALIS <petros@cfp.mit.edu> 25

SMTP Forwarding and Conversation

Mostly direct transfer from sender host to receiver host May go through intermediate machine via forwarding

capability Sender can specify route Target user may have moved

SMTP limited to conversation between sender and receiver Main function is to transfer messages Rest of mail handling beyond scope of SMTP

May differ between systems

Petros KAVASSALIS <petros@cfp.mit.edu> 26

Main operations (1)

Connection setup Exchange of command-response pairs Connection termination

Connection setup Sender opens TCP connection with receiver Once connected, receiver identifies itself Sender identifies itself Receiver accepts sender’s identification (If mail service not available, step 2 above becomes: service not

available)

Petros KAVASSALIS <petros@cfp.mit.edu> 27

Main operations (2)

Connection setup Exchange of command-response pairs Connection termination Exchange of command-response pairs

Sender may send one or more messages to receiver MAIL command identifies originator Gives reverse path to used for error reporting Receiver returns 250 OK or appropriate fail/error message One or more RCPT commands identifies recipients for the message Separate reply for each recipient DATA command transfers message text End of message indicated by line containing just period (.)

Petros KAVASSALIS <petros@cfp.mit.edu> 28

Main operations (3)

Connection setup Exchange of command-response pairs Connection termination

Connection termination Sender sends QUIT and waits for reply Then initiate TCP close operation Receiver initiates TCP close after sending reply to QUIT

Petros KAVASSALIS <petros@cfp.mit.edu> 29

Mail access protocols

SMTP: delivery/storage to receiver’s server Mail access protocol: retrieval from server

POP: Post Office Protocol [RFC 1939]o authorization (agent <-->server) and download

IMAP: Internet Mail Access Protocol [RFC 1730]o more features (more complex)o manipulation of stored msgs on server

HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Petros KAVASSALIS <petros@cfp.mit.edu> 30

useragent

sender’s mail server

useragent

SMTP SMTP accessprotocol

receiver’s mail server

MIME

Extension to RFC822 SMTP can not transmit executables

Uuencode and other schemes are availableo Not standardized

Can not transmit text including international characters (e.g. â, å, ä, è, é, ê, ë) Need 8 bit ASCII

Servers may reject mail over certain size Translation between ASCII and EBCDIC not standard Some SMTP implementations do not adhere to standard

CRLF, truncate or wrap long lines, removal of white space, etc.

Petros KAVASSALIS <petros@cfp.mit.edu> 31

MIME in a nutshell

Five new message header fields MIME version Content type Content transfer encoding Content Id Content Description

Number of content formats defines

Transfer encoding defined

Petros KAVASSALIS <petros@cfp.mit.edu> 32

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data

Content types

Text body Multipart

Mixed, Parallel, Alternative, Digest Message

RFC 822, Partial, External-body Image

jpeg, gif Video

mpeg Audio

Basic Application

Postscript octet stream

Petros KAVASSALIS <petros@cfp.mit.edu> 33