Additional API functions and data-structures

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

2. 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 );

3. 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

4. Message-header struct msghdr { void *msg_name; // optional address socklen_t msg_namelen; // size of address struct iovec *msg_iov; // scatter/gather array int msg_iovlen; // no. of members void *msg_control; // ancillary data buffer int msg_controllen; // ancillary buffer length int flags; // 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.

5. 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 char smallbuf[ 128 ], largebuf[ 1400 ]; struct iovec myiovec[ 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.

6. ‘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

7. 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 Application Layer Transport Layer Transport Layer Network Layer Network Layer Link Layer Link Layer Physical Layer Physical Layer

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

9. ICMP messages Type Message 8 or 0 Echo request or reply ICMP Query messages 13 or 14 Timestamp request and reply 17 or 18 Address Mask request and reply 10 or 9 Router solicitation and advertisement 3 Destination unreachable 4 Source quench ICMP Error reporting messages 11 Time exceeded 12 Parameter problem 5 Redirection

10. Type 3: Destination unreachable Code Reason 0 The network is unreachable 1 The host is unreachable 2 The protocol is unreachable 3 The port is unreachable 4 Fragmentation needed (but DF is set) 5 Source routing cannot be accomplished 6 Destination network is unknown 7 Destination host is unknown Several additional code-values can occur for Type 3

11. 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

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

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

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