TDC561 Network Programming

1
TDC561 Network Programming
Week 1 Course Introduction Socket Application
Programming Interface Examples C/C UNIX/Linux
APIs

• Camelia Zlatea, PhD
• Email czlatea_at_cs.depaul.edu

2
TDC561 Course Summary

• Topics
• TCP/IP protocol suite
• Socket programming TCP and UDP sockets Reliable
  UDP Communication
• Client-Server Models
• Socket options
• Threads concurrency locking
• Select calls
• Non-Blocking I/O
• IOCTL
• ICMP
• Broadcast/Multicast
• Programming aspects related to network performance

3
Objectives

• Upon completion of this course, students will
• have a good understanding of the TCP/UDP network
  programming interface
• be able to develop client-server network
  applications on the Internet, based on UNIX/Linux
• know how to apply methods for measuring and
  tuning the performance of network applications

4
Prerequisites

• TDC 463, CSC 309
• C/C will be used to illustrate the concepts
  presented in the lecture material and for the
  implementation of the programming assignments and
  the project.
• Basic understanding of UNIX / Linux operating
  system and programming environment

5
Texts

• Douglas Comer, David Stevens, Internetworking
  with TCP/IP Client-Server Programming, Volume
  III (BSD Unix and ANSI C), 2nd edition, 1996
  (ISBN 0-13-260969-X)
• W. Richard Stevens, Network Programming
  Networking API Sockets and XTI, Volume 1, 2nd
  edition, 1997 (ISBN 0-13-490012-X)

6
Other References

• L.Peterson, B. Davie. Computer Networks A System
  Approach. Morgan Kaufman, 2000. (ISBN
  1-55860-514-2)
• W. Stallings. Local and Metropolitan Area
  Networks. Prentice Hall,2000. (ISBN 0130129390)
• W. Richard Stevens, Network Programming
  Inter-process Communication, Volume 2, 2nd
  edition, 1999 (ISBN 0-13-081081-9)
• Robertazzi, Thomas G., Computer Networks and
  Systems - Queuing Theory and Performance
  Evaluation, second edition, Springer Verlag, 1994

7
Class Work and Grading
Programming Assignment 1 20 due by January 21th
Programming Assignment 2 20 due by February 4rd
Programming Assignment 3 20 due by February 18th
Programming Assignment 4 20 due by March 4rd
Final Project 20 due by March 18th
8
Programming Environment

• All students will get an account on
  hawk.depaul.edu server (running HP-UX).
• Optional, you can use Linux system
• Project submissions via COL ( dlweb.cti.depaul.edu
  )
• use Submit Assignments link
• Grading will be done on HP-UX or Linux
• An experimental report is required for each
  programming project
• The the report should include the program design
  description and the test cases and test
  scenarios for the application.

9
TDC561 Network Programming

• Instructor Camelia Zlatea, PhD
• Office Hours T 445-545PM 900-930PM
• Where Rm. 429, ext. x26149 (during office hours)
• Email czlatea_at_cs.depaul.edu
• Web http//condor.depaul.edu/czlatea/TDC561/
  ()
• Note
• In addition, course materials will be available
  from dlweb.cti.depaul.edu

10
Class Communication

• COL (dlweb.cti.depaul.edu) will be used primarily
  for
• Links to course materials/assignments
• Grades
• Announcements
• Email/Communication
• Newsgroup
• Asking questions
• Send me an email at czlatea_at_cs.depaul.edu
  OR
• Use dlweb.cti.depaul.edu and post questions to
  class forum
• Anybody may reply (including your classmates)
• Everyone benefits from common issues

11
Socket APIs C/C UNIX/Linux Systems Calls (APIs)
12
References

• Douglas Comer, David Stevens, Internetworking
  with TCP/IP Client-Server Programming, Volume
  III (BSD Unix and ANSI C), 2nd edition, 1996
  (ISBN 0-13-260969-X)
• Chap. 3,4,5
• W. Richard Stevens, Network Programming
  Networking API Sockets and XTI, Volume 1, 2nd
  edition, 1998 (ISBN 0-13-490012-X)
• Chap. 1,2,3,4
• John Shapley Gray, Interprocess Communications in
  UNIX -- The Nooks and Crannies Prentice Hall PTR,
  NJ, 1998
• Chap. 10

13
Client Server Communication

• The transport protocols TCP and UDP were designed
  to enable communication between network
  applications
• Internet host can have several servers running.
• usually has only one physical link to the rest
  of the world
• When packets arrive how does the host identify
  which packets should go to which server?
• Ports
• ports are used as logical connections between
  network applications
• 16 bit number (65536 possible ports)
• demultiplexing key
• identify the application/process to receive the
  packet
• TCP connection
• source IP address and source port number
• destination IP address and destination port
  number
• the combination IP Address Port Number pair is
  called a Socket

14
Client Server Communication
Port
IP
Network Host
Network
122.34.45.67
Network Host
123.45.67.89
SOCKETS
122.34.45.67 65534
123.45.67.8980
15
Client Server Communication
Port
HTTP Server with three active connections
(sockets).
IP Network
Active
Active
Active
Listening
IP Host/ Server
The HTTP server listens for future connections.
16
Ports

• Port - A 16-bit number that identifies the
  application process that receives an incoming
  message.
• Port numbers divided into three categories
• Well Known Ports 0-1023
• Registered Ports 1024-49151 by the IANA
  (Internet Assigned Numbers Authority), and
  represent second tier common ports (socks (1080),
  WINS (1512), kermit (1649), https (443))
• Dynamic/Private Ports 49152-65535 ephemeral
  ports, available for temporary client usage
• Reserved ports or well-known ports (0 to 1023)
• Standard ports for well-known applications.
• See /etc/services file on any UNIX machine for
  listing of services on reserved ports.
• 1 TCP Port Service Multiplexer
• 20 File Transfer Protocol (FTP) Data
• 21 FTP Control
• 23 Telnet
• 25 Simple Mail Transfer (SMT)
• 43 Who Is
• 69 Trivial File Transfer Protocol (TFTP)
• 80 HTTP

17
Associations

• A socket address is the triplet
• protocol, local-IP, local-port
• example,
• tcp, 130.245.1.44, 23
• An association is the 5-tuple that completely
  specifies the two end-points that comprise a
  connection
• protocol, local-IP, local-port, remote-IP,
  remote-port
• example
• tcp, 130.245.1.44, 23, 130.245.1.45, 1024

18
Socket Domain Families

• There are several significant socket domain
  families
• Internet Domain Sockets (AF_INET)
• implemented via IP addresses and port numbers
• Unix Domain Sockets (AF_UNIX)
• implemented via filenames (similar to IPC named
  pipe)

19
Creating a Socket

• include ltsys/types.hgt
• include ltsys/socket.hgt
• int socket(int domain, int type, int protocol)
• domain is one of the Protocol Families (AF_INET,
  AF_UNIX, etc.)
• type defines the communication protocol
  semantics, usually defines either
• SOCK_STREAM connection-oriented stream (TCP)
• SOCK_DGRAM connectionless, unreliable (UDP)
• protocol specifies a particular protocol, just
  set this to 0 to accept the default

20
The Socket Structure

• INET Address
• struct in_addr
• in_addr_t s_addr / 32-bit IPv4 address /
• INET Socket
• Struct sockaddr_in
• uint8_t sin_len / length of structure (16) /
• sa_family_t sin_family / AF_INET /
• in_port_t sin_port / 16-bit TCP/UDP port
  number /
• struct in_addr sin_addr / 32-bit IPv4 address
  /
• char sin_zero8 / unused /

21
Setup for an Internet Domain Socket

• struct sockaddr_in
• sa_family_t sin_family
• unsigned short int sin_port
• struct in_addr sin_addr
• unsigned char pad...
• sin_family is set to Address Family AF_INET
• sin_port is set to the port number you want to
  bind to
• sin_addr is set to the IP address of the machine
  you are binding to (struct in_addr is a wrapper
  struct for an unsigned long)
• ignore padding

22
Stream Socket Transaction (TCP Connection)
Server
socket()
Client
bind()
socket()
listen()
3-way handshake
connect()
accept()
write()
data
read()
data
write()
read()
EOF
close()
read()
close()
23

• Connection-oriented socket connections
• Client-Server view

24
Server Side Socket Details
25
Client Side Socket Details
26
Reading From and Writing To Stream Sockets

• Sockets, are inter-process-communication
  mechanism, similar with files
• low level IO
• read() system call
• write() system call
• higher level IO
• int recv(int socket, char buf, int len, int
  flags)
• blocks on read
• returns 0 when other connection has terminated
• int send(int socket, char buf, int len, int
  flags)
• returns the number of bytes actually sent
• where flags may be one of
• MSG_DONTROUTE (dont route out of localnet)
• MSG_OOB (out of band data (causes interruption))
• MSG_PEEK (examine, but dont remove from stream)

27
Closing a Socket Session

• int close(int socket)
• closes read/write IO, closes socket file
  descriptor
• int shutdown( int socketfd, int mode)
• where mode is
• 0 no more receives allowed r
• 1 no more sends are allowed w
• 2 disables both receives and sends (but doesnt
  close the socket, use close() for that) rw

28
Byte Ordering

• Different computer architectures use different
  byte ordering to represent/store multi-byte
  values (such as 16-bit/32-bit integers)
• 16 bit integer

Little-Endian (Intel)
Big-Endian (RISC-Sparc)
Low Byte
High Byte
Address A
High Byte
Low Byte
Address A1
29
Byte Order and Networking

• Suppose a Big Endian machine sends a 16 bit
  integer with the value 2
• A Little Endian machine will understand the
  number as 512
• How do two machines with different byte-orders
  communicate?
• Using network byte-order
• Network byte-order big-endian order

0000000000000010
0000001000000000
30
Network Byte Order

• Conversion of application-level data is left up
  to the presentation layer.
• Lower level layers communicate using a fixed byte
  order called network byte order for all control
  data.
• TCP/IP mandates that big-endian byte ordering be
  used for transmitting protocol information
• All values stored in a sockaddr_in must be in
  network byte order.
• sin_port a TCP/IP port number.
• sin_addr an IP address.

31
Network Byte Order Functions

• Several functions are provided to allow
  conversion between host and network byte
  ordering,
• Conversion macros (ltnetinet/in.hgt)
• to translate 32-bit numbers (i.e. IP addresses)
• unsigned long htonl(unsigned long hostlong)
• unsigned long ntohl(unsigned long netlong)
• to translate 16-bit numbers (i.e. Port numbers)
• unsigned short htons(unsigned short hostshort)
• unsigned short ntohs(unsigned short netshort)

32
TCP Sockets Programming Summary

• Creating a passive mode (server) socket.
• Establishing an application-level connection.
• send/receive data.
• Terminating a connection.

33
Creating a TCP socket

• int socket(int family,int type,int proto)
• int mysockfd
• mysockfd socket( AF_INET, SOCK_STREAM,
• 0)
• if (mysockfdlt0) / ERROR /

34
Binding to well known address

• int mysockfd
• int err
• struct sockaddr_in myaddr
• mysockfd socket(AF_INET,SOCK_STREAM,0)
• myaddr.sin_family AF_INET
• myaddr.sin_port htons( 80 )
• myaddr.sin_addr htonl( INADDR_ANY )
• err bind(mysockfd, (sockaddr ) myaddr,
  sizeof(myaddr))

35
Bind What Port Number?

• Clients typically dont care what port they are
  assigned.
• When you call bind you can tell it to assign you
  any available port
• myaddr.port htons(0)

36
Bind - What IP address ?

• How can you find out what your IP address is so
  you can tell bind() ?
• There is no realistic way for you to know the
  right IP address to give bind() - what if the
  computer has multiple network interfaces?
• Specify the IP address as INADDR_ANY, this tells
  the OS to handle the IP address specification.

37
Converting Between IP Address formats

• From ASCII to numeric
• 130.245.1.44 ? 32-bit network byte ordered
  value
• inet_aton() with IPv4
• inet_pton() with IPv4 and IPv6
• From numeric to ASCII
• 32-bit value ? 130.245.1.44
• inet_ntoa() with IPv4
• inet_ntop() with IPv4 and IPv6
• Note inet_addr() obsolete
• cannot handle broadcast address 255.255.255.255
  (0xFFFFFFFF)

38
IPv4 Address Conversion

• int inet_aton( char , struct in_addr )
• Convert ASCII dotted-decimal IP address to
  network byte order 32 bit value. Returns 1 on
  success, 0 on failure.
• char inet_ntoa(struct in_addr)
• Convert network byte ordered value to ASCII
  dotted-decimal (a string).

39
Establishing a passive mode TCP socket

• Passive mode
• Address already determined.
• Tell the kernel to accept incoming connection
  requests directed at the socket address.
• 3-way handshake
• Tell the kernel to queue incoming connections for
  us.

40
listen()

• int listen( int mysockfd, int backlog)
• mysockfd is the TCP socket (already bound to an
  address)
• backlog is the number of incoming connections the
  kernel should be able to keep track of (queue for
  us).
• listen() returns -1 on error (otherwise 0).

41
Accepting an incoming connection

• Once we call listen(), the O.S. will queue
  incoming connections
• Handles the 3-way handshake
• Queues up multiple connections.
• When our application is ready to handle a new
  connection, we need to ask the O.S. for the next
  connection.

42
accept()

• int accept( int mysockfd,
• struct sockaddr cliaddr,
• socklen_t addrlen)
• mysockfd is the passive mode TCP socket.
• cliaddr is a pointer to allocated space.
• addrlen is a value-result argument
• must be set to the size of cliaddr
• on return, will be set to be the number of used
  bytes in cliaddr.
• accept() return value
• accept() returns a new socket descriptor
  (positive integer) or -1 on error.
• After accept returns a new socket descriptor, I/O
  can be done using the read() and write() system
  calls.

43
Terminating a TCP connection

• Either end of the connection can call the close()
  system call.
• If the other end has closed the connection, and
  there is no buffered data, reading from a TCP
  socket returns 0 to indicate EOF.

44
Client Code

• TCP clients can call connect() which
• takes care of establishing an endpoint address
  for the client socket.
• dont need to call bind first, the O.S. will
  take care of assigning the local endpoint address
  (TCP port number, IP address).
• Attempts to establish a connection to the
  specified server.
• 3-way handshake

45
connect()

• int connect( int sockfd,
• const struct sockaddr server,
• socklen_t addrlen)
• sockfd is an already created TCP socket.
• server contains the address of the server (IP
  Address and TCP port number)
• connect() returns 0 if OK, -1 on error

46
Reading from a TCP socket

• int read( int fd, char buf, int max)
• By default read() will block until data is
  available.
• reading from a TCP socket may return less than
  max bytes (whatever is available).

47
Writing to a TCP socket

• int write( int fd, char buf, int num)
• write might not be able to write all num bytes
  (on a nonblocking socket).
• Other functions (API)
• readn(), writen() and readline() - see man pages
  definitions.

48
Example from R. Stevens text
Client Server communication
Server
Client
Network
Machine B
Machine A

• Web browser and server
• FTP client and server
• Telnet client and server

49
Example Daytime Server/Client
Application protocol (end-to-end logical
connection)
Daytime client
Daytime server
Socket API
Socket API
TCP protocol (end-to-end logical connection)
TCP
TCP
IP protocol (physical connection )
IP
IP
MAC-level protocol (physical connection )
MAC driver
MAC driver
Actual data flow
MAC media access control
Network
50
Daytime client

• include "unp.h"
• int main(int argc, char argv)
• int sockfd, n
• char recvlineMAXLINE 1
• struct sockaddr_in servaddr
• if( argc ! 2 )err_quit(usage gettime ltIP
  addressgt)
• / Create a TCP socket /
• if ( (sockfd socket(AF_INET, SOCK_STREAM,
  0)) lt 0)
• err_sys("socket error")
• / Specify servers IP address and port
  /
• bzero(servaddr, sizeof(servaddr))
• servaddr.sin_family AF_INET
• servaddr.sin_port htons(13) / daytime
  server port /

• Connects to a daytime server
• Retrieves the current date and time
• gettime 130.245.1.44
• Thu Sept 05 155000 2002

51
Daytime client

• / Connect to the server /
• if (connect(sockfd, (SA ) servaddr,
  sizeof(servaddr)) lt 0)
• err_sys("connect error")
• / Read the date/time from socket /
• while ( (n read(sockfd, recvline,
  MAXLINE)) gt 0)
• recvlinen 0 / null
  terminate /
• printf(s, recvline)
• if (n lt 0) err_sys("read error")
• close(sockfd)

52
Simplifying error-handling R. Stevens

• int Socket(int family, int type, int protocol)
• int n
• if ( (n socket(family, type, protocol)) lt
  0)
• err_sys("socket error")
• return n

53
Daytime Server

• include "unp.h"
• include lttime.hgt
• int main(int argc, char argv)
• int listenfd, connfd
• struct sockaddr_in servaddr
• char buffMAXLINE
• time_t ticks
• / Create a TCP socket /
• listenfd Socket(AF_INET, SOCK_STREAM,
  0)
• / Initialize servers 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 /

• Waits for requests from Client
• Accepts client connections
• Send the current time
• Terminates connection and goes back waiting for
  more connections.

54
Daytime Server

• / Convert socket to a listening socket
  /
• Listen(listenfd, LISTENQ)
• for ( )
• / Wait for client connections
  and accept them /
• connfd Accept(listenfd, (SA )
  NULL, NULL)
• / Retrieve system time /
• ticks time(NULL)
• snprintf(buff, sizeof(buff),
  ".24s\r\n", ctime(ticks))
• / Write to socket /
• Write(connfd, buff,
  strlen(buff))
• / Close the connection /
• Close(connfd)

55
Background SlidesTCP/IP Protocol Suite - Terms
and Concepts
56
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

57
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

58
UDP
59
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

60
TCP

• Reliable Byte-Stream
• Connection-oriented
• Byte-stream
• sending process writes some number of bytes
• TCP breaks into segments and sends via IP
• receiving process reads some number of bytes
• Full duplex
• Flow control keep sender from overrunning
  receiver
• Congestion control keep sender from overrunning
  network

61
TCP

• Connection-oriented protocol
• logical connection created between two
  communicating processes
• connection is managed at TCP protocol layer
• provides reliable and sequential delivery of data
• receiver acknowledgements sender that data has
  arrived safely
• sender resends data that has not been
  acknowledged
• packets contain sequence numbers so they may be
  ordered
• Bi-directional byte stream
• both sender and receiver write and read bytes
• acknowledgements identify received bytes
• buffers hold data until there is a sent
• multiple bytes are packaged into a segment when
  sent

62
TCP End-to-End Issues

• Based on sliding window protocol used at data
  link
• level, but the situation is very different.
• Potentially connects many different hosts
• need explicit connection establishment and
  termination
• Potentially different RTT (Round Trip Time)
• need adaptive timeout mechanism
• Potentially long delay in network
• need to be prepared for arrival of very old
  packets
• Potentially different capacity at destination
• need to accommodate different amounts of
  buffering
• Potentially different network capacity
• need to be prepared for network congestion

63
TCP Segment Format

• Every TCP segment includes a Sequence Number that
  refers to the first byte of data included in the
  segment.
• Every TCP segment includes an Acknowledgement
  Number that indicates the byte number of the next
  data that is expected to be received.
• All bytes up through this number have already
  been received.
• Control flags
• URG urgent data included.
• ACK this segment is (among other things) an
  acknowledgement.
• RST error - abort the session.
• SYN synchronize Sequence Numbers (setup)
• FIN polite connection termination.
• Window
• Every ACK includes a Window field that tells the
  sender how many bytes it can send before the
  receiver buffer will be in overflow

64
TCP Segment Format
0
16
31
Source Port Number
Destination Port Number
Sequence Number
Acknowledgement
0
Flags
Window
Hdr Len
Checksum
Urgent Pointer
Options/Padding
Data
65
TCP Connection Establishment and Termination

• When a client requests a connection it sends a
  SYN segment (a special TCP segment) to the
  server port.
• SYN stands for synchronize. The SYN message
  includes the clients SN.
• SN is Sequence Number.

66
TCP Connection Creation
Client Active Participant
Server Passive Participant
SYN SNX
1
SYN SNY ACKX1
2
ACKY1
3
67
TCP 3-Way Handshake

• A client starts by sending a SYN segment with the
  following information
• Clients SN (generated pseudo-randomly) X
• Maximum Receive Window for client.
• Only TCP headers
• When a waiting server sees a new connection
  request, the server sends back a SYN segment
  with
• Servers SN (generated pseudo-randomly) Y
• Acknowledgement Number is Client SN1 X1
• Maximum Receive Window for server.
• Only TCP headers
• When the Servers SYN is received, the client
  sends back an ACK with
• Acknowledgement Number is Servers SN1 Y1
• Why 3-way?

1
2
3
68
TCP Data and ACK

• Once the connection is established, data can be
  sent.
• Each data segment includes a sequence number
  identifying the first byte in the segment.
• Each segment (data or empty) includes an
  acknowledgement number indicating what data has
  been received.

69
TCP

• Reliable Byte-Stream
• Connection-oriented
• Byte-stream
• sending process writes some number of bytes
• TCP breaks into segments and sends via IP
• receiving process reads some number of bytes
• Full duplex
• Flow control keep sender from overrunning
  receiver
• Congestion control keep sender from overrunning
  network

70
TCP Buffering

• The TCP layer doesnt know when the application
  will ask for any received data.
• TCP buffers incoming data so its ready when we
  ask for it.
• Client and server allocate buffers to hold
  incoming and outgoing data
• The TCP layer does this.
• Client and server announce with every ACK how
  much buffer space remains (the Window field in a
  TCP segment).
• Most TCP implementations will accept out-of-order
  segments (if there is room in the buffer).
• Once the missing segments arrive, a single ACK
  can be sent for the whole thing.

71
TCP Buffering

• Send Buffers
• The application gives the TCP layer some data to
  send.
• The data is put in a send buffer, where it stays
  until the data is ACKd.
• The TCP layer wont accept data from the
  application unless (or until) there is buffer
  space.
• ACK
• A receiver doesnt have to ACK every segment (it
  can ACK many segments with a single ACK segment).
• Each ACK can also contain outgoing data
  (piggybacking).
• If a sender doesnt get an ACK after some time
  limit it resends the data.

72
Termination

• The TCP layer can send a RST segment that
  terminates a connection if something is wrong.
• Usually the application tells TCP to terminate
  the connection gracefully with a FIN segment.
• FIN
• Either end of the connection can initiate
  termination.
• A FIN is sent, which means the application is
  done sending data.
• The FIN is ACKd.
• The other end must now send a FIN.
• That FIN must be ACKd.

73
TCP Connection Termination
App2
App1
FIN SNX
1
ACKX1
2
...
FIN SNY
3
ACKY1
4
74
Stream Sockets

• Connection-Based, i.e., socket addresses
  established before sending messages between C/S
• Address Domain AF_UNIX (UNIX pathname) or
  AF_INET (hostport)
• Virtual Circuit i.e., Data Transmitted
  sequentially in a reliable and non-duplicated
  manner
• Default Protocol Interface is TCP
• Checks order, sequence, duplicates
• No boundaries are imposed on data (its a stream
  of bytes)
• Slower than UDP
• Requires more program overhead

75
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