1 / 22

TDC561 Network Programming

TDC561 Network Programming. Week 2 – part II: Socket Application Programming Interface – UDP Socket;. Camelia Zlatea, PhD Email: czlatea@cs.depaul.edu. UDP Clients and Servers. Connectionless clients and servers create a socket using SOCK_DGRAM instead of SOCK_STREAM

Ava
Télécharger la présentation

TDC561 Network Programming

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. TDC561 Network Programming Week 2 – part II: Socket Application Programming Interface – UDP Socket; Camelia Zlatea, PhD Email: czlatea@cs.depaul.edu

  2. UDP Clients and Servers • Connectionless clients and servers create a socket using SOCK_DGRAM instead of SOCK_STREAM • Connectionless servers do not call listen() or accept(), and usually do not call connect() • Since connectionless communications lack a sustained connection, several methods are available that allow you to specify a destination addresswith every call: • sendto(sock, buffer, buflen, flags, to_addr, tolen); • recvfrom(sock, buffer, buflen, flags, from_addr, fromlen)

  3. Datagram Socket Transaction (UDP Connection) Server Client socket() socket() bind() sendto() data recvfrom() data sendto() recvfrom() close()

  4. UDP Client and Server Client Flows • Client Flow • Create UDP socket. • Create sockaddr with address of server. • Call sendto(), sending request to the server. • If a reply is needed, call recvfrom() • Server Flow • Create UDP socket and bind to well known address. • Call recvfrom() to get a request, notifying the address of the client. • Process request and send reply back with sendto().

  5. Creating a UDP socket int socket(int family,int type,int proto); int sock; sock = socket( AF_INET, SOCK_DGRAM, 0); if (sock<0) { /* ERROR */ }

  6. Binding to well known address int mysock; struct sockaddr_in myaddr; mysock = socket(AF_INET,SOCK_DGRAM,0); myaddr.sin_family = AF_INET; myaddr.sin_port = htons( 6990 ); myaddr.sin_addr = htonl( INADDR_ANY ); bind(mysock, &myaddr, sizeof(myaddr));

  7. Sending UDP Datagrams ssize_t sendto( int sockfd, void *buff, size_t nbytes, int flags, const struct sockaddr* to, socklen_t addrlen); sockfd is a UDP socket buff is the address of the data (nbytes long) to is the address of a sockaddr containing the destination address. Return value is the number of bytes sent, or -1 on error.

  8. Sending UDP Datagrams • Return Value sendto() • indicates how much data was accepted by the Kernel (OS) for sending as a datagram • does NOT say how much data actually reached the destination. • Errors from sendto() EBADF, ENOTSOCK: bad socket descriptor EFAULT: bad buffer address EMSGSIZE: message too large ENOBUFS: system buffers are full • No error condition to indicate that the destination did not get receive the datagram

  9. Receiving UDP Datagrams ssize_t recvfrom( int sockfd, void *buff, size_t nbytes, int flags, struct sockaddr* from, socklen_t *fromaddrlen); sockfd is a UDP socket buff is the address of a buffer (nbytes long) from is the address of a sockaddr. Return value is the number of bytes received and put into buff, or -1 on error.

  10. Receiving UDP Datagrams • If buff is not large enough, any extra data is lost • The sockaddr at from is filled in with the address of the sender. • The fromaddrlen should be set before invoking. • If from and fromaddrlen are NULL there is no way to identify who sent the data. • Same errors as sendto, but also: • EINTR: System call interrupted by signal. • Blocking operation ( by default ) • recvfrom doesn’t return until there is a datagram available • waiting/blocking time can be indefinite

  11. UDP Echo Server int mysock; struct sockaddr_in myaddr, cliaddr; char msgbuf[MAXLEN]; socklen_t clilen; int msglen; mysock = socket(AF_INET,SOCK_DGRAM,0); myaddr.sin_family = AF_INET; myaddr.sin_port = htons( S_PORT ); myaddr.sin_addr = htonl( INADDR_ANY ); bind(mysock, &myaddr, sizeof(myaddr)); while (1) { len=sizeof(cliaddr); msglen=recvfrom(mysock,msgbuf,MAXLEN,0,cliaddr,&clilen); sendto(mysock,msgbuf,msglen,0,cliaddr,clilen); }

  12. UDP Daytime Client and Server • Server waits for requests on a known port. • Client sends a UDP request to server. • Server responds with daytime info. • No connection establishment! • No reliability!

  13. UDP Server #include "unp.h" #include <time.h> int main(int argc, char **argv) { int sockfd, clilen; struct sockaddr_in servaddr, cliaddr; char buff[MAXLINE], req[REQ_LEN]; time_t ticks; /* Create a socket */ sockfd = Socket(AF_INET, SOCK_DGRAM, 0); /* Initialize server’s address and well-known port */ bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(13); /* daytime server */ /* Bind server’s address and port to the socket */ Bind(sockfd, (struct sockaddr *) &servaddr, sizeof(servaddr));

  14. UDP Server for ( ; ; ) { /* Wait for client request */ len = sizeof(cliaddr); n = Recvfrom( sockfd, req, REQ_LEN, 0, &cliaddr, &clilen); /* Retrieve the system time */ ticks = time(NULL); snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks)); /* Send to client*/ Sendto(sockfd, buff, strlen(buff), 0, &cliaddr, clilen); } }

  15. UDP Client #include "unp.h" int main(int argc, char **argv) { int sockfd, n, servlen; char req[10], recvline[MAXLINE + 1]; struct sockaddr_in servaddr; if( argc != 2 )err_quit(“usage : gettime <IP address>”); /* Create a UDP socket */ sockfd = Socket(AF_INET, SOCK_DGRAM, 0); /* Specify server’s IP address and port */ bzero(&servaddr, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_port = htons(13); /* daytime server port */ Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);

  16. UDP Client /* Send message to server requesting date/time */ strcpy(req, “GET_TIME”); Sendto(sockfd, req, strlen(req), 0, (struct sockaddr *)&servaddr, sizeof(servaddr)); /* Read date/time from the socket */ servlen = sizeof(servaddr); n= Recvfrom(sockfd, recvline, MAXLINE, 0, (struct sockaddr *)&servaddr, &servlen); recvlen[n] = 0; printf(“%s”, recvlen); close(sockfd); }

  17. Background SlidesUDP Protocol - Terms and Concepts

  18. TCP/IP Summary • IP: network layer protocol • unreliable datagram delivery between hosts. • UDP: transport layer protocol - provides fast / unreliable datagram service. Pros: Less overhead; fast and efficient • minimal datagram delivery service between processes. • unreliable, since there is no acknowledgement of receipt, there is no way to know to resend a lost packet • no built-in order of delivery, random delivery • connectionless; a connection exists only long enough to deliver a single packet • checksum to guarantee integrity of packet data • TCP: transport layer protocol . Cons: Lots of overhead • connection-oriented, full-duplex, reliable, byte-stream delivery service between processes. • guaranteed delivery of packets in order of transmission by offering acknowledgement and retransmission: • sequenced delivery to the application layer, by adding a sequence number to every packet. • checksum to guarantee integrity of packet data

  19. End-to-End (Transport) Protocols • Underlying best-effort network • drops messages • re-orders messages • delivers duplicate copies of a given message • limits messages to some finite size • delivers messages after an arbitrarily long delay • Common end-to-end services • guarantee message delivery • deliver messages in the same order they are sent • deliver at most one copy of each message • support arbitrarily large messages • support synchronization • allow the receiver to apply flow control to the sender • support multiple application processes on each host

  20. UDP Application Application Application process process process Ports Queues Packets demultiplexed UDP Packets arrive

  21. UDP Header 0 16 31 Src Port Address Dst Port Address Checksum Length of DATA DATA • Simple Demultiplexor • Unreliable and unordered datagram service • Adds multiplexing • No flow control • Endpoints identified by ports • servers have well-known ports • see /etc/services on Unix • Optional checksum • pseudo header + udp header + data • UDP Packet Format

  22. Datagram Sockets • Connectionless sockets, i.e., C/S addresses are passed along with each message sent from one process to another • Peer-to-Peer Communication • Provides an interface to the UDP datagram services • Handles network transmission as independent packets • Provides no guarantees, although it does include a checksum • Does not detect duplicates • Does not determine sequence • ie information can be lost, wrong order or duplicated

More Related