Additional API functions and data-structures A look at how some information from lower-layers of the TCP/IP protocol stack could be accessed

Two more socket functions Besides the ‘sendto()’ and ‘recvfrom()’ socket-functions (or ‘send()’ and ‘recv()’), there are two further functions which will be essential to make use of in particular programming situations ssize_t sendmsg( int sock, struct msghdr *msghdr, int flags ); ssize_t recvmsg( int sock, struct msghdr *msghdr, int flags );

More data-structures… The ‘sendmsg()’ and ‘recvmsg()’ functions make use of a special data-structure that collects a group of parameters into a neat package, called a ‘message header’, and supports use of ‘scatter-gather’ operations by using an array of ‘I/O-vector’ objects struct iovec { void *iov_base; size_t iov_len; } Each I/O-vector describes a memory-buffer, giving its address and its length

Message-header struct msghdr { void*msg_name;// optional address socklen_tmsg_namelen;// size of address struct iovec*msg_iov;// scatter/gather array intmsg_iovlen;// no. of members void*msg_control;// ancillary data buffer intmsg_controllen;// ancillary buffer length intflags;// flags on received message }; This structure is used as a value-result parameter in the ‘recvmsg()’ function, and is used as a value-only parameter in the ‘sendmsg()’ function.

Idea for a ‘scatter’ example If most of your application’s messages are short ones, but sometimes there could be a larger one, then you could allocate one oversized buffer to handle the occasional ‘overflow’ from your small-size buffers charsmallbuf[ 128 ], largebuf[ 1400 ]; struct iovecmyiovec[ 2 ] = { { smallbuf, 128 }, { largebuf, 1400 } }; Data scattering: The arriving data will be accumulated in the small buffer until it is filled, then any overflow will be accumulated in the large buffer.

‘Ancillary’ data Our main interest in using the ‘recvmsg()’ socket-function will be to obtain ancillary information – specifically, we want to see details about ‘message-delivery’ failures which normally are not available outside the Linux kernel’s networking subsystem Some ‘socket options’ will make the extra information available to an application

ICMP The Internet Control Message Protocol is used for relaying information between the code-modules at the ‘network’ level of the TCP/IP protocol stack (e.g., for reporting errors and for various system queries) Application Layer Transport Layer Network Layer Link Layer Physical Layer Application Layer Transport Layer Network Layer Link Layer Physical Layer

ICMP packet-format Ethernet Header Internet Protocol Header ICMP Header Data Rest of the ICMP Header (layout varies with the Type) ChecksumCodeType 32 bits

ICMP messages Echo request or reply Timestamp request and reply Address Mask request and reply Router solicitation and advertisement Source quench Destination unreachable Time exceeded Parameter problem Redirection or 9 17 or or 14 8 or 0 Type Message ICMP Query messages ICMP Error reporting messages

Type 3: Destination unreachable The network is unreachable The host is unreachable The protocol is unreachable The port is unreachable Fragmentation needed (but DF is set) Source routing cannot be accomplished Destination network is unknown Destination host is unknown Several additional code-values can occur for Type 3 CodeReason

Our msgserver and msgclient We posted a new client-and-server demo in which exchanges of network messages is accomplished by using the ‘sendmsg()’ and the ‘recvmsg()’ socket functions and accompanying ‘message-header’ objects With ‘nicwatch’ we can use these demos to illustrate the ICMP protocol in action

ICMP protocol Type 0: Echo Reply Type 8: Echo Request

UDP protocol ICMP protocol Type 11: Time exceeded Code 0: (always zero for Type 11)

UDP protocol ICMP protocol Type 3: Destination unreachable Code 3: The port is unreachable