1 / 46

Application Layer: Mail, FTP, DNS

Application Layer: Mail, FTP, DNS. Teacher: Bahjat Qazzaz. Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent Also called “mail reader” Allows composing, reading, forwarding, replying to mail messages… In 1990 GUI agents became popular

drake-banks
Download Presentation

Application Layer: Mail, FTP, DNS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Layer: Mail, FTP, DNS Teacher: Bahjat Qazzaz Application Layer

  2. Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent Also called “mail reader” Allows composing, reading, forwarding, replying to mail messages… In 1990 GUI agents became popular e.g., Eudora, Outlook, elm, Netscape Messenger user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server outgoing message queue user mailbox Electronic Mail Application Layer

  3. Mail Servers mailbox manages and maintains incoming messages for user messagequeue of outgoing (to be sent) mail messages SMTP protocol between mail servers to send email messages Client side: runs on the sending mail server Server side: runs on the receiving mail server user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server Electronic Mail: mail servers Application Layer

  4. uses TCP to reliably transfer email message from client to server, port 25 direct transfer: sending server to receiving server three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction Electronic Mail: SMTP [RFC 2821] Application Layer

  5. 1) Ali uses UA to compose message and “to” bob@someschool.edu 2) Ali’s UA sends message to his mail server; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob’s mail server 4) SMTP client sends Ali’s message over the TCP connection 5) Bob’s mail server places the message in Bob’s mailbox 6) Bob invokes his user agent to read message user agent user agent mail server mail server Scenario: Ali sends message to Bob 1 2 6 3 4 5 Application Layer

  6. SMTP: delivery/storage to receiver’s server Mail access protocol: retrieval from server POP3: Post Office Protocol-Version 3 [RFC 1939] authorization (agent <-->server) and download IMAP: Internet Mail Access Protocol [RFC 2060] more features (more complex) manipulation of stored msgs on server HTTP: Hotmail , Yahoo! Mail, etc. user agent user agent sender’s mail server SMTP Mail access protocols SMTP access protocol receiver’s mail server Application Layer

  7. Three phases: 1. authorization phase client send the commands: user: username pass: password server responses +OK (command has executed) or –ERR (some thing wrong has happened). 2. transaction phase, client: list: list message numbers retr: retrieve messages dele: mark messages for deletion Quit 3. Update phase: server deletes the messages marked for deletion after the user quits. POP3 protocol*1 Application Layer

  8. More about POP3 “download and delete” mode partitions messages over multiple machines. So, user cannot re-read e-mail if he is nomadic (views e-mail from different PCs) User can create local folders but not remote ones. “Download-and-keep” mode keeps messages on the mail server after being downloaded IMAP Keep all messages in one place: the server Associate the arriving messages to INBOX folder Allows user to organize messages in folders (remote folders from the point view of the user) Allows searching the folders Download parts of the message IMAP keeps user state across sessions: names of folders and mappings between message IDs and folder name POP3 (more) and IMAP Application Layer

  9. The user agent is an ordinary web browser. And, the user communicate with its remote mail box via HTTP. So, when a client wants to access his e-mail, the messages move from the mail server to the browser using HTTP rather than POP3 IMAP protocol. Also, the message is sent from the sender browser to the e-mail server using HTTP rather than SMTP. أذكر بعض الفوائد لهذا النوع.....من أي مكان....التخزين.....مجاناً!!!!!!!!!!!!!!! Web-Based E-mail Application Layer

  10. People can be identified by: ID#, name, passport # Internet hosts, also, can be identify by: IP address (e.g. 127.7.106.83) - used by routers “name”(e.g., popeye.cs.school.edu) - used by humans Routers prefer and uses IP addresses The main task of DNS: Is to translates host names to IP addresses DNS protocol run over UDP and uses port 53 It is employed by application layers such as HTTP, SMTP, and FTP. DNS servers are often UNIX machines running the Berkeley Internet Name Domain (BIND). DNS: Domain Name System Application Layer

  11. What does happen when a user requests a URL? Let’s say: www.webpage.edu/index.html The users’ host must obtain the IP addrees of www.webpage.edu The same user machine runs the client side of the DNS application The browser passes the host name www.webpage.edu to the client side of the DNS application The DNS client a query containing the host name to a DNS server The DNS client receives a reply, which includes the IP address for the hostname. The browser gets the IP address and initiates a TCP connection to the HTTP server of the located IP address. Example: Application Layer

  12. Domain Name System: distributed database implemented in a hierarchy of many name servers application-layer protocol host, name servers to communicate to resolvenames (address/name translation) core Internet function, implemented as application-layer protocol (use UDP and port 53) complexity at network’s “edge” DNS: Domain Name System Application Layer

  13. no server has all name-to-IP address mappings local name servers: each local ISP has a 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! DNS name servers Application Layer

  14. 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 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 k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA DNS: Root name servers 13 root name servers worldwide Application Layer

  15. 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 local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu Application Layer

  16. Root name server: may not know authoritative name server may know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu Application Layer

  17. recursive query: puts burden of name resolution on contacted name server iterative query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterative queries root name server iterative query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu Application Layer

  18. once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time reduce DNS delay and DNS traffic DNS caching Application Layer

  19. Remote Login :TELNET • Text-oriented interface • User • Invokes client • –Specifies remote computer • Client • Forms TCP connection to server • Passes keystrokes over connection • Displays output on screen Application Layer

  20. File Transfer • Complete file copy • Major protocol is File Transfer Protocol (FTP) • Uses TCP • Supports binary or text transfers • Large set of commands • Until 1995 was major source of packets in Interne Application Layer

  21. FTP Paradigm • Command-line interface • User Forms TCP connection to server (called control connection) – Logs in – Enters commands to list directories, transfer files • Server – Establishes new TCP connection for each transfer Application Layer

  22. Client server programming Characteristics Of A Clint Arbitrary application program, temporarily Invoked directly by user and Runs locally Actively initiates contact with a server Contacts one server at a time Characteristics Of A Server Special-purpose, privileged program Dedicated to providing one service Can handle multiple remote clients simultaneously Invoked automatically when system boots Executes forever (waits for clients to contact) Application Layer

  23. a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process socket Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API • client/server paradigm • explicitly created, used, released by apps • two types of transport service via socket API: • UDP socket: unreliable datagram • TCP socket: reliable, byte-stream-oriented Application Layer

  24. process process TCP with buffers, variables TCP with buffers, variables socket socket Socket-programming using TCP Socket: a door between application process and transport protocol (UCP or TCP) TCP service: reliable, in-order transfer of bytesfrom one process to another controlled by application developer controlled by application developer controlled by operating system controlled by operating system internet host or server host or server Application Layer

  25. Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket establish a connection to server’s socket When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint Socket programming with TCP Application Layer

  26. Socket Programming Using TCP: Flow Diagram client server socket() socket() bind() listen() TCP 3-way handshake connect() accept() Data (request) write() read() Data (reply) read() write() close() close() Application Layer

  27. The socket() System Call int socket(int family, int type, int protocol) • address family: AF_INET for Internet addresses • socket type: • SOCK_STREAM: supported by TCP. Connection-oriented and reliable. Message boundaries are not preserved. • SOCK_DGRAM: supported by UDP. Connectionless and unreliable. Message boundaries are maintained. • protocol: 0 • Return value: a socket descriptor that can be used to reference the socket in subsequent system calls. –1 on error. • Example: sock=socket(AF_INET, SOCK_STREAM, 0) returns a TCP stream socket Application Layer

  28. The bind() System Call int bind(int sockfd, struct sockaddr *addr, int addrlen) • Bind an address to the socket • sockfd: socket descriptor • struct sockaddr{ short sa_family; /*address family*/ char sa_data[14]; /*up to 14 bytes of address*/ } • addrlen: size of addr structure • Return value: 0 for success, -1 for error. Application Layer

  29. Internet Domain Address /* Internet socket address structure */ struct sockaddr_in { short sin_family; /*AF_INET*/ u_short sin_port; /*16-bit port no., network byte order */ struct in_addr sin_addr;/*32-bit Internet address, network byte order*/ char sin_zero[8]; /*unused*/ }; /* Internet address */ struct in_addr { u_long s_addr; }; Application Layer

  30. The bind() System Call: An Example int sockfd; struct sockaddr_in myaddr; if ((sockfd=socket(AF_INET, SOCK_STREAM, 0))<0) {/*handle error*/} myaddr.sin_family=AF_INET; myaddr.sin_port=htons(5100); //all ports below 1024 are RESERVED myaddr.sin_addr.s_addr=htonl(INADDR_ANY); if (bind(sockfd, (struct sockaddr *) &myaddr, sizeof(myaddr))<0) {/*handle error*/} Note: cast sockaddr_in to sockaddr in bind(). Application Layer

  31. Listen(), Accept(), Connect() int listen(int sockfd, int maxwaiting) • Called by server, ready to accept requests • Initialize a queue for incoming connection requests. int accept(int sockfd, struct sockaddr *fromaddr, int *addrlen) • sockfd used for accepting incoming connection requests • Take the first pending connection request off the queue and create a new socket (return value) for communicating with client • The address of the client socket is returned in fromaddr • Block until client connects int connect(int sockfd, struct sockaddr *toaddr, int addrlen) • Called by client • Blocking, return when accepted Application Layer

  32. Sending and Receiving Data int read(int sockfd, char *buffer, int n) read n bytes from a socket and store them in buffer. int write(int sockfd, char *buffer, int n) write n bytes stored in buffer to a socket • read and write return the number of bytes read/written or -1 if they fail. Application Layer

  33. A Simple Server Using TCP Socket #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #define MYPORT 3490 // the port users will be connecting to #define BACKLOG 10 // how many pending connections queue will hold int main() { int sockfd, new_fd; // listen on sockfd, new connection on new_fd struct sockaddr_in my_addr; // my address information struct sockaddr_in their_addr; // client's address information int sin_size; Application Layer

  34. A Simple Server Using TCP Socket if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } my_addr.sin_family = AF_INET; my_addr.sin_port = htons(MYPORT); my_addr.sin_addr.s_addr = htonl(INADDR_ANY); // automatically fill with my IP if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)) == -1) { perror("bind"); exit(1); } if (listen(sockfd, BACKLOG) == -1) { perror("listen"); exit(1); } Application Layer

  35. A Simple Server Using TCP Socket while(1) { sin_size = sizeof(struct sockaddr_in); if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr, &sin_size)) == -1) { perror("accept"); continue; } printf("server: got connection from %s\n", inet_ntoa(their_addr.sin_addr)); if (write(new_fd, "Hello, world!\n", 14) < 0) { perror("send"); exit(1); } close(new_fd); } } Application Layer

  36. A Simple Client Using TCP Socket #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <string.h> #include <netdb.h> #include <sys/types.h> #include <netinet/in.h> #include <sys/socket.h> #define PORT 3490 // the port client will be connecting to #define MAXDATASIZE 100 // max number of bytes we can get at once int main(int argc, char *argv[]) { int sockfd, numbytes; char buf[MAXDATASIZE]; struct hostent *he; struct sockaddr_in their_addr; // server's address information Application Layer

  37. A Simple Client Using TCP Socket if (argc != 2) { fprintf(stderr,"usage: client hostname\n"); exit(1); } if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } if ((he=gethostbyname(argv[1])) == NULL) { // get the host info perror("gethostbyname"); exit(1); } their_addr.sin_family = AF_INET; their_addr.sin_port = htons(PORT); memcpy(&their_addr.sin_addr, he->h_addr, he->h_length); Application Layer

  38. A Simple Client Using TCP Socket if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof(struct sockaddr)) == -1 { perror("connect"); exit(1); } if ((numbytes=read(sockfd, buf, MAXDATASIZE)) < 0) { perror("read"); exit(1); } printf("Received: %s",buf); close(sockfd); } Application Layer

  39. UDP: no “connection” between client and server no handshaking sender explicitly specifies the address of the destination for each packet UDP: transmitted data may be received out of order, or lost UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server application viewpoint Socket programming with UDP Application Layer

  40. Socket Programming Using UDP: Flow Diagram client server socket() socket() bind() Data (request) recvfrom() sendto() Data (reply) sendto() recvfrom() close() close() Application Layer

  41. Sending via UDP Socket: sendto() int sendto (int sockfd, char *buff, int bufflen, int flags, struct sockaddr *toaddr, int tolen) • sockfd: socket descriptor • buff: a set of consecutive memory locations holding the message to send • bufflen: number of bytes to send • flags: 0 • toaddr: address of sockaddr_in structure holding destination address info. • tolen: length of destination address • Return value: length of data actually sent. –1 if error. Application Layer

  42. Reading from UDP Socket: recvfrom() int recvfrom (int sockfd, char *buff, int bufflen, int flags, struct sockaddr *fromaddr, int *fromlen) • sockfd: socket descriptor • buff: a set of consecutive memory locations holding the message to be received • bufflen: number of bytes to read • flags: 0 • fromaddr: address of sockaddr_in structure containing address info of socket that sent the data. A returned value. • tolen: size of the address structure. A returned value. • Retun value: number of bytes actually received. –1 of error. Application Layer

  43. #include <stdio.h> #include <errno.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <netinet/in.h> #include <netdb.h> #define MY_PORT_ID 6090 main (int argc, char *argv[ ]) { int sockid, nread, addrlen; struct sockaddr_in myaddr, client_addr; char msg[50]; if ((sockid=socket(AF_INET, SOCK_DGRAM, 0))<0) {printf(“server: socket error: %d\n”, errno); exit(0);} myaddr.sin_family=AF_INET; myaddr.sin_port=htons(MY_PORT_ID); myaddr.sin_addr.s_addr=htonl(INADDR_ANY); if (bind(sockid, (struct sockaddr *) &myaddr, sizeof(myaddr)))<0 {printf(“server: bind fail: %d\n”, errno); exit(0);}; nread=recvfrom(sockid,msg,11,0,(struct sockaddr*)&client_addr, &addrlen)); If (nread>0) printf(“server: message is %s\n”,msg); close(sockid); } A Simple Example Server Using UDP Socket Application Layer

  44. #include <stdio.h> #include <errno.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <netinet/in.h> #include <netdb.h> #define SERVER_PORT_ID 6090 #define SERV_HOST_ADDR “129.186.3.91” main (int argc, char *argv[ ]) { int sockid, retcode; struct sockaddr_in myaddr, server_addr; char msg[12]; if ((sockid=socket(AF_INET, SOCK_DGRAM, 0))<0) {printf(“client: socket error: %d\n”, errno); exit(0);} server_addr.sin_family=AF_INET; server_addr.sin_port=htons(SERVER_PORT_ID); server_addr.sin_addr.s_addr=inet_addr(SERV_HOST_ADDR); sprintf(msg, “hello world”); retcode=sendto(sockid,msg,11,0,(struct sockaddr*)&server_addr, sizeof(server_addr)); If (retcode==-1) {printf(“client: sendto failed: %d\n”,errno); exit(0);} close(sockid); } A Simple Example Client Using UDP Socket Application Layer

  45. application service requirements: reliability, bandwidth, delay client-server paradigm Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP specific protocols: HTTP SMTP3, POP, IMAP DNS socket programming Our study of network apps now complete! Summary Application Layer

  46. typical request/reply message exchange: client requests info or service server responds with data, status code message formats: headers: fields giving info about data data: info being communicated Most importantly: learned about protocols Summary Application Layer

More Related