TDC561 - Network Programming

Download Report

Transcript TDC561 - Network Programming

TDC561
Network Programming
Week 2 – part II:
Socket Application Programming Interface – UDP Socket;
Camelia Zlatea, PhD
Email: [email protected]
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)
Network Programming (TDC561)
Winter 2003
Page 2
Datagram Socket Transaction (UDP Connection)
Server
Client
socket()
socket()
bind()
sendto()
data
recvfrom()
data
sendto()
recvfrom()
close()
Network Programming (TDC561)
Winter 2003
Page 3
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().
Network Programming (TDC561)
Winter 2003
Page 4
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 */ }
Network Programming (TDC561)
Winter 2003
Page 5
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));
Network Programming (TDC561)
Winter 2003
Page 6
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.
Network Programming (TDC561)
Winter 2003
Page 7
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
Network Programming (TDC561)
Winter 2003
Page 8
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.
Network Programming (TDC561)
Winter 2003
Page 9
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
Network Programming (TDC561)
Winter 2003
Page 10
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);
}
Network Programming (TDC561)
Winter 2003
Page 11
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!
Network Programming (TDC561)
Winter 2003
Page 12
UDP Server
#include
#include
"unp.h"
<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));
Network Programming (TDC561)
Winter 2003
Page 13
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);
}
}
Network Programming (TDC561)
Winter 2003
Page 14
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);
Network Programming (TDC561)
Winter 2003
Page 15
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);
}
Network Programming (TDC561)
Winter 2003
Page 16
Background Slides
UDP Protocol - Terms and Concepts
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
Network Programming (TDC561)
Winter 2003
Page 18
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
Network Programming (TDC561)
Winter 2003
Page 19
UDP
Application
process
Application
process
Application
process
Ports
Queues
Packets
demultiplexed
UDP
Packets arrive
Network Programming (TDC561)
Winter 2003
Page 20
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
Header

0
16
31
Src Port Address
Dst Port Address
Checksum
Length of DATA
DATA
Network Programming (TDC561)
Winter 2003
Page 21
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
Network Programming (TDC561)
Winter 2003
Page 22