On receiving ancillary data

1. On receiving ancillary data We use the ‘recvmsg()’ function to obtain a datagram’s arrival-time as a UDP socket option

2. The ‘traceroute’ algorithm • The idea is to send out a succession of packets to an internet destination, with increasing values for the IP header’s ‘Time-to-Live’ field, knowing that whenever any packet arrives at a router, its ‘Time-to-Live’ field will get decremented • Routers discard packets whose TTL is zero, and return an ICMP error-message ‘Time Exceeded’ to the sender which shows that router’s identity • Then this routing information can be displayed

3. Algorithm implementation • Probably the most natural way to think about implementing this ‘traceroute’ idea would be to send ICMP ‘Echo Requests’ • When the ‘Time-to-Live field is sufficiently large, the ICMP Echo Request will arrive at its intended target, and an ‘Echo Reply’ ICMP message would get sent back, as with the well known ‘ping’ network utility

4. Sending ICMP packets Echo Request to D (TTL=1) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Time Exceeded to A Echo Request to D (TTL=2) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Time Exceeded to A Echo Request to D (TTL=3) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Echo Reply to A

5. Need a RAW socket • For a Linux application to send an ICMP message, it has to open a type of socket which normally requires ‘root’ privileges • You can look at our ‘nicwatch’ utility for an example that uses a RAW socket to access the fields in a packet’s headers • Without ‘root’ privileges we can’t write a ‘traceroute’ utility that is based on ICMP

6. The Linux ‘workaround’ • What we can do instead is to send UDP datagrams which have increasing values for the TTL-field in their IP-headers (since the TTL-field for any outgoing packets is something that an unprivileged application program can control with a ‘socket option’) • We can detect the identity of routers that send us ‘Time Exceeded’ messages by looking at ‘ancillary data’ via ‘recvmsg()’

7. Sending UDP packets UDP message to D (TTL=1) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Time Exceeded to A UDP message to D (TTL=2) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Time Exceeded to A UDP message to D (TTL=3) 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 10.0.3.1 10.0.3.2 Host A Host B Host C Host D Destinnation Unreachable to A

8. Using an unlikely port? • The most common way of getting back an ‘Destination Unreachable’ error-message (ICMP Type 3) is by sending a datagram to a UDP port which is not being used by any applications currently running on the destination host (ICMP Type 3, Code 3: Port is unreachable) – but a sender might not possess that knowledge for certain, thus a ‘best guess’ approach can be tried

9. Other UDP senarios… • We might never get any response from a destination host – e.g., our datagram DID arrive at its destination successfully, and thus ‘sendmsg()’ times out while waiting • Or our destination host lies behind some ‘firewall’ that has been erected along the path, or a intermediate router could be configured to ‘block’ an ICMP response

10. Your project #1 • Your first programming challenge is to try implementing your own miniature version of the ‘traceroute’ utility, devising your own way of handling the less common senarios • The main requirement will be to display the IP-addresses for the various routers encountered along a path to your target • Enhance that basic capability: extra credit

11. 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 }; struct iovec { void *iov_base; size_t iov_len; }

12. Ancillary control-data The ancillary data that is returned by ‘sendmsg()’ in the buffer pointed to by its message-header’s ‘cmsg_control’ field is delivered in a succession of one or more packages, each beginning with this ‘struct cmsghdr’ format, whose data may be followed by padding to achieve a required alignment. struct cmsghdr { socklen_t cmsg_len; // data byte count, including header int cmsg_level; // originating protocol’s ID-number int cmsg_type; // protocol-specific type ID-number unsigned char cmsg_data[0]; // variable amount of data follows }; To avoid the compiler generating code that would be architecture-dependent, these packages of ancillary data should be accessed using special macros named CMSG_FIRSTHDR(), CMSG_DATA(), CMSG_NXTHDR(), etc., and defined for Linux systems in the header-file </usr/include/linux/socket.h>.

13. Demo: ‘triptime.cpp’ • We illustrate the role of socket options and access to ancillary data with this example, which sends a datagram to a host that is running our ‘msgserver’ echo-server, and uses a ‘timestamp’ that our socket binds to the returned datagram to get the packet’s round-trip travel-time (in microseconds) message to server $ ./triptime stargate 54321 $ ./msgserver reply from server stargate round-trip travel-time

14. The SO_TIMESTAMP option • When this socket-layer option is enabled, and a suitably sized buffer is provided for the specified ancillary data, the network protocol software reports the arrival-time of the datagram messages it receives • Comparing arrival-time to departure-time allows calculating a ‘round-trip’ travel-time

15. ‘setsockopt()’ • Here are the code-fragments used to open a datagram socket, and then to enable its ability to ‘timestamp’ any arriving packets int sock = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP ); if ( sock < 0 ) { perror( “socket” ); exit(1); } int oval = 1; int olen = sizeof( oval ); if ( setsockopt( sock, SOL_SOCKET, SO_TIMESTAMP, &oval, olen ) < 0 ) { perror( “setsockopt TIMESTAMP” ); exit(1); }

16. ‘struct timeval’ • Linux systems support a data-structure that allows ‘time-of-day’ to be accurately recorded (in seconds and microseconds) seconds micoseconds + struct timeval { unsigned long tv_sec; unsigned long tv_usec; }; This structure-type is defined in the header-file </usr/include/sys/time.h>

17. ‘gettimeofday()’ • This library-function records the current time-of-day in a ‘struct timeval’ record • Our ‘triptime.cpp’ example uses this to get the departure-time of an outgoing packet # declare a ‘struct timeval’ object struct timeval now; # store the current time based on the system’s clock gettimeofday( &now, NULL );

18. The ‘cbuf’ array • The arrival-time for a received packet may be obtained using the ‘recvmsg()’ function with a suitably initialized message-header • For the case of receiving timestamp data, the ‘struct cmsg’ buffer will need room for a ‘struct timeval’ object as its ‘cmsg_data’, in addition to its ‘struct cmsghdr’ header • We need to know sizes for C data-types

19. Types for x86_64 Linux • On our x86_64 Linux platform, the sizes for ‘int’ and ‘long’ are 32-bits and 64-bits, respectively, so we’ll need buffer-space that can store 16 (=8+4+4) bytes for the ‘struct cmsghdr’ header, plus 16 (=8+8) bytes for the ‘struct timeval’ data-object • (Our demo actually allocates 40 bytes)

20. Initializing ‘mymsghdr’ • Here are code-fragments that prepare our ‘struct msghdr’ for receiving the timestamp unsigned char buf[ 40 ] = { 0 }, cbuf[ 40 ] = { 0 }; struct iovec myiov[1] = { { buf, 40 } }; struct msghdr mymsghdr; mymsghdr.msg_name = &paddr; // server socket-address mymsghdr.msg_namelen = sizeof( paddr ); // socket-address length mymsghdr.msg_iov = myiov; // address of I/O-vector mymsghdr.msg_iovlen = 1; // elements in I/O-vector mymsghdr.msg_control = cbuf; // address for control data mymsghdr.msg_controllen = sizeof( cbuf ); // control data buffer size mymsghdr.msg_flags = 0; // flag settings (none) int rx = recvmsg( sock, &mymsghdr, 0 ); // receive the datagram if ( rx < 0 ) { perror( “recvmsg” ); exit(1); }

21. Using the macros • Here is how we use the system’s macros to get the ‘timestamp’ on the arriving data struct timeval tvrecv; int tlen = sizeof( struct timeval ); struct msghdr *msgp = &mymsghdr; struct cmsghdr *cmsg; for ( cmsg = CMSG_FIRSTHDR( msgp ); cmsg != NULL; cmsg = CMSG_NXTHDR( msgp, cmsg ) ) { if (( cmsg->cmsg_level == SOL_SOCKET ) &&( cmsg->cmsg_type == SO_TIMESTAMP )) memcpy( &tvrecv, CMSG_DATA( cmsg ), tlen ); }

22. Computing RTT • The Round-Trip travel-time can be gotten by a subtraction (arrival minus departure) provided we convert each ‘struct timeval’ record into a single numerical value that expresses these times in microseconds # convert structures to numbers (one-million microseconds per second) unsigned long long stamp0 = tvsend.tv_sec * 1000000LL + tvsend.tv_usec; unsigned long long stamp1 = tvrecv.tv_sec * 1000000LL + tvrecv.tv_usec; # subtract departure-time from arrival-time to get the ‘round-trip’ travel-time unsigned long long rtt = stamp1 – stamp0;

23. Observation • Our ‘msgserver.cpp’ echo-server program performs a certain amount of processing between the time it receives a datagram and the time it sends back its response: • It displays a report about the packet’s size • It displays the text of the packet’s message • It modifies a member of its I/O-vector array • These steps take some time – which gets included in the client’s round-trip measure

24. In-class exercises • Could you reduce the size of the ‘cbuf[40]’ array in our ‘triptime.cpp’ application, since it appears the timestamp and its cmsghdr could fit in fewer than 40 bytes of storage? • Could you shrink the round-trip travel-time by a noticeable number of microseconds if you omitted the server’s system-calls that write information to the screen-display?