Presentation is loading. Please wait.

Presentation is loading. Please wait.

TDC561 Network Programming Camelia Zlatea, PhD Week 2 – part II: Socket Application Programming Interface.

Similar presentations


Presentation on theme: "TDC561 Network Programming Camelia Zlatea, PhD Week 2 – part II: Socket Application Programming Interface."— Presentation transcript:

1 TDC561 Network Programming Camelia Zlatea, PhD Email: czlatea@cs.depaul.educzlatea@cs.depaul.edu Week 2 – part II: Socket Application Programming Interface – UDP Socket;

2 Network Programming (TDC561)Page 2 Winter 2003 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 address with every call: –sendto(sock, buffer, buflen, flags, to_addr, tolen); –recvfrom(sock, buffer, buflen, flags, from_addr, fromlen)

3 Network Programming (TDC561)Page 3 Winter 2003 Datagram Socket Transaction (UDP Connection) socket() bind() socket() sendto() recvfrom() close() recvfrom() sendto() data Client Server

4 Network Programming (TDC561)Page 4 Winter 2003 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 Network Programming (TDC561)Page 5 Winter 2003 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 Network Programming (TDC561)Page 6 Winter 2003 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 Network Programming (TDC561)Page 7 Winter 2003 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 Network Programming (TDC561)Page 8 Winter 2003 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 Network Programming (TDC561)Page 9 Winter 2003 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 Network Programming (TDC561)Page 10 Winter 2003 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 Network Programming (TDC561)Page 11 Winter 2003 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 Network Programming (TDC561)Page 12 Winter 2003 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 Network Programming (TDC561)Page 13 Winter 2003 #include "unp.h" #include 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)); UDP Server

14 Network Programming (TDC561)Page 14 Winter 2003 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); } UDP Server

15 Network Programming (TDC561)Page 15 Winter 2003 #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 ”); /* 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); UDP Client

16 Network Programming (TDC561)Page 16 Winter 2003 /* 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); } UDP Client

17 Background Slides UDP Protocol - Terms and Concepts

18 Network Programming (TDC561)Page 18 Winter 2003 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 Network Programming (TDC561)Page 19 Winter 2003  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 End-to-End (Transport) Protocols

20 Network Programming (TDC561)Page 20 Winter 2003 UDP Application process Application process Application process UDP Packets arrive Ports Queues Packets demultiplexed

21 Network Programming (TDC561)Page 21 Winter 2003 UDP  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 Src Port AddressDst Port Address ChecksumLength of DATA DATA 01631 Header

22 Network Programming (TDC561)Page 22 Winter 2003 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


Download ppt "TDC561 Network Programming Camelia Zlatea, PhD Week 2 – part II: Socket Application Programming Interface."

Similar presentations


Ads by Google