Advanced Socket Programming Issues

1
Advanced Socket Programming Issues

• by
• Serkan Çamurcuoglu
• Bilgin Metin

2
Contents

• Advanced Name and Address Conversions
• Daemons and the inetd Superserver
• Receiving flags, destination IP and received
  interface
• Adding reliability to a UDP application
• Binding Interface Addresses
• Signal Driven I/O
• Raw Sockets
• Datalink Access

3
Name and Address Conversions

• struct hostent gethostbyaddr(64.56.4.4,addrlen,
  addrtype)
• struct hostent gethostbyname(mail.yahoo.com)
• int gethostname(buf,MAXNAMELEN)
• int getpeername(fd,(struct sockaddr)addr,adrrle
  n)
• struct protoent getprotobyname(icmp)
• struct protoent getprotobynumber(6)
• struct servent getservbyname(www)
• struct servent getservbyport(23)
• int getsockname(fd,(struct sockaddr)addr,
  addrlen)
• struct hostent
• char h_name char h_aliases
• int h_addrtype int h_length
• char h_addr_list

4
Name and Address Conversions

• But these functions require a priori knowledge of
  address type (IPv4 or IPv6). So we cant write
  protocol independent code easily.
• Posix1.g standard defines a new function
  getaddrinfo.
• int getaddrinfo(const char hostname, const char
  service, const struct addrinfo hints, strcut
  addrinfo result)
• struct addrinfo
• int ai_flags int ai_family
• int ai_socktype int ai_protocol
• size_t ai_addrlen char ai_canonname
• struct sockaddr ai_addr
• struct sockaddr ai_next

5
Name and Address Conversions

• getaddrinfo() returns a linked list of address
  info structures
• Some hints about the desired kinds of addresses
  may be given in the hints argument
• getaddrinfo dynamically allocates memory unlike
  its predecessor functions
• The corresponding freeaddrinfo() function is
  called to free the buffers that are allocated by
  getaddrinfo().

6
Daemons and the inetd superserver

• A daemon process is a process that runs in the
  background and is independent of control from all
  terminals.
• Daemons can be started by system initialization
  scripts or by other daemons (e.g. inetd, cron..
  etc.)
• Since daemons have no controlling terminals, they
  cant print to standard error, they send their
  messages to the syslogd daemon.
• A process can daemonize itself as shown in the
  daemon_init() function.

7
The inetd superserver

• All daemons contain similar startup code and they
  are asleep most of the time. So, the inetd
  superserver does
• Create a socket for all services specified in
  inetd.conf
• Bind well-known addresses to these sockets
• Call listen() on TCP sockets
• Then call select() for readability on all sockets
• When a socket becomes readable, call fork() and
  then exec() the server to handle the request

8
Receiving flags, destination IP and the receiving
interface for a UDP socket

• recvfrom() can return the destination IP address,
  but it does not return any flags and does not
  help to determine on which index the datagram was
  received.
• To do this, create a UDP socket and set the
  socket options IP_RECVDSTADDR and IP_RECVIF
• Then call recvfrom_flags() which is a wrapper
  function of recvmsg().

9
TCP vs. UDP

• UDP supports broadcast and multicast and does not
  have connection setup or teardown. But a UDP
  application will have to provide
  acknowledgements, retransmissions, flow control..
  etc.
• So UDP is used for mcast, bcast and simple
  request-reply applications such as DNS, TFTP and
  SNMP.
• You should prepend a sequence to each datagram
• Retransmission timeout is calculated based on the
  measured round-trip time (RTT) and some
  statistical estimators. Datagrams are timestamped
  to measure the RTT.

10
Binding Interface Addresses

• A server application may want to bind all
  interface addresses so that it handles all
  requests that arrive at all interfaces
• The list of all interfaces might be obtained by
  using the SIOCGIFCONF ioctl or sysctl().
• The server forks a child for each address that it
  binds
• The application can bind the broadcast and the
  wildcard addresses

11
Concurrent UDP Servers

• If the processing of a client request takes a
  long time, some form of concurrency is needed.
• Its easy in TCP to fork a new child for every
  connection because a socket pair is unique
• But in UDP, when the servers forks a child, it
  creates a new socket, binds an ephemeral port to
  that socket, and uses this port for all its
  replies
• Therefore, the client has to look at the servers
  first reply and send its subsequent requests to
  the new port

12
Signal Driven I/O

• Signal driven I/O is asynchronous I/O because the
  process is interrupted when I/O occurs. The UNIX
  signal for I/O is SIGIO. For signal driven I/O
• A signal handler for SIGIO is established
• The socket owner is set as the process itself
• Signal driven I/O must be enabled by setting
  FIOASYNC ioctl
• For convenience, non-blocking I/O may be required
• In UDP, an I/O signal is generated whenever a
  datagram arrives or an asynchronous error occurs

13
Signal Driven I/O

• However in TCP, I/O signals are generated too
  frequently (conn. completed, disconn. initiated,
  disconn. completed, half of connection is shut
  down, data arrived, data sent and async. error
  occurred). Therefore signal driven I/O is not
  suitable for TCP.
• In practice, Network Time Protocol (NTP) servers
  use signal driven I/O with UDP.

14
Raw Sockets

• Raw sockets let us read and write ICMP and IGMP
  packets and other packets that are not processed
  by the kernel (e.g. OSPF packets)
• Raw sockets enable us to create our own IP header
  and other headers inside it by using the
  IP_HDRINCL socket option
• Only the superuser can create a raw socket
• rawfd socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)

15
Raw Sockets

• Normally sendto() and sendmsg() is used to send
  data from raw sockets
• Note On Linux, all fields of the IP header must
  be in network byte order
• UDP TCP packets are never passed to raw sockets
• Most ICMP messages, all IGMP messages and
  datagrams with an unknown protocol field are
  passed to raw sockets
• Examples ping and traceroute.

16
Datalink Access

• Datalink layer access from the sockets interface
  provides us the ability to capture all packets on
  the network and the ability to run some programs
  such as a RARP server as a normal application
  instead of being a part of the kernel
• BSD Packet Filter, System V Datalink Provider
  Interface and Linux SOCK_PACKET
• fd socket(AF_INET, SOCK_PACKET,
  htons(ETH_P_ALL))
• The packet capture library libpcap is publicly
  available and works on all platforms