Simple Network Time Protocol - Essay Example

RFC 2030 Network Time Protocol (NTP Network Time Protocol is used to synchronize computer clocks in World Wide Web scenario. It has been describedby Network Working Group in their Request for Comments: 1305 specifications. NTP standardize the process of time synchronization between national time and frequency dissemination services helps in time synchronization of subnet of a network. It helps in adjusting the local clock in each participating subnet peer in a local network. It promises the accuracies of 1-50 ms, depending on the characteristics of the synchronization source and network paths. RFC-1305 specifies the NTP Version 3 protocol machine in terms of events, states, transition unctions and actions and, in addition, engineered algorithms to improve the timekeeping quality and mitigate among several synchronization sources, some of which may be faulty. To achieve accuracies in the low milliseconds over paths spanning major portions of the Internet of today, these intricate algorithms, or their functional equivalents, are necessary. However, in many cases accuracies in the order of significant fractions of a second are acceptable. In such cases, simpler protocols such as the Time Protocol, have been used for this purpose. These protocols usually involve an RPC exchange where the client requests the time of day and the server returns it in seconds past some known reference epoch. Simple Network Time Protocol: Introduction SNTP has been described by Network Working Group in their Request for Comments: 1305 specifications. It is a simplified version of Network Time Protocol for servers and clients. It is particularly useful for the client and server machines which were using NTP version 3 to shift over internet and World Wide Web. SNTP is designed to operate in a dedicated server configuration including an integrated radio clock. SNTP protocols can be used to fetch time from NTP server to synchronize client subnet machines. They can not be used to synchronize time between their peer client machines of the network. SNTP can be used to achieve a time accuracy of microseconds if all the factors causing network time latency are considered properly while designing and implementing the protocol. Working of SNTP Client An SNTP client can work in one of following modes: Unicast Mode In unicast mode, the client sends a request for time stamp to a unicast server and expects a reply from that server. Multicast Mode In multicast mode, the client sends no request and waits for a broadcast of time stamp from a designated multicast server. Anycast Mode In anycast mode, the client sends a request to a designated local broadcast or multicast group address and expects a reply from one or more anycast servers. The first reply received by the SNTP client is used for subsequent unicast requests from designated server and client stops responding to other server replies. Other than the selection of address in the request, the operations of anycast and unicast clients are identical. Requests are normally sent at intervals from 64 s to 1024 s, depending on the frequency tolerance of the client clock and the required accuracy. A unicast or anycast client initializes the NTP message header, sends the request to the server and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all of the NTP header fields shown above can be set to 0, except the first octet and (optional) Transmit Timestamp fields. In the first octet, the LI field is set to 0 (no warning) and the Mode field is set to 3 (client). The VN field must agree with the version number of the NTP/SNTP server; however, Version 4 servers will also accept previous versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers already accept all previous versions, including Version 1 (RFC-1059). As different versions of NTP and SNTP servers are deployed over the Internet, designing a NTP or SNTP clients should be given proper attention to maintain interoperability. It could be better practice to use latest versions of NTP/SNTP clients that are supported by the selected server in for a better accuracy and reliability. SNTP Version 4 clients can interoperate with all previous versions of NTP and SNTP servers, since the header fields used by SNTP clients are unchanged. Version 4 servers are required to reply in the same version as the request, so the VN field of the request also specifies the version of the reply. While not necessary in a conforming client implementation, in unicast and anycast modes it highly recommended that the transmit timestamp in the request is set to the time of day according to the client clock in NTP timestamp format. This allows a simple calculation to determine the propagation delay between the server and client and to align the local clock generally within a few tens of milliseconds relative to the server. In addition, this provides a simple method to verify that the server reply is in fact a legitimate response to the specific client request and avoid replays. In multicast mode, the Client has no information to calculate the propagation delay or determine the validity of the server, unless the NTP authentication scheme is used. A unicast client initializes the NTP message header, sends the request to the server, and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all the NTP header fields shown above are set to 0, except the Mode, VN, and optional Transmit Timestamp fields. NTP and SNTP clients set the mode field to 3 (client) for unicast and manycast requests. They set the VN field to any version number that is supported by the server, selected by configuration or discovery, and that can interoperate with all previous version NTP and SNTP servers. Servers reply with the same version as the request, so the VN field of the request also specifies the VN field of the reply. A prudent SNTP client can specify the earliest acceptable version on the expectation that any server of that or a later version will respond. NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers accept all previous versions, including Version 1 (RFC 1059). Version 0 (RFC 959) is now not supported by NTP and SNTP servers. Although setting the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format is not necessary in a conforming client implementation, it is highly recommended in unicast and manycast modes. This allows a simple calculation to determine the propagation delay between the server and client and to align the system clock generally within a few tens of milliseconds relative to the server. In addition, this provides a simple method for verifying that the server reply is in fact a legitimate response to the specific client request and thereby for avoiding replays. In broadcast mode, the client has no information to calculate the propagation delay or to determine the validity of the server, unless one of the NTP authentication schemes is used. To calculate the roundtrip delay d and system clock offset t relative to the server, the client sets the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format. For this purpose, the clock need not be synchronized. The server copies this field to the Originate Timestamp in the reply and sets the Receive Timestamp and Transmit Timestamp fields to the time of day according to the server clock in NTP timestamp format. When the server reply is received, the client determines a Destination Timestamp variable as the time of arrival according to its clock in NTP timestamp format. The following table summarizes the four timestamps. Timestamp Name ID When Generated Originate Timestamp Receive Timestamp Transmit Timestamp Destination Timestamp T1 T2 T3 T4 time request sent by client time request received by server time reply sent by server time reply received by client The roundtrip delay d and system clock offset t are defined as: d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2 SNTP Message Format Following figure shows NTP and SNTP message format; this follows the IP and UDP headers in the message. This format is identical to the NTP message format described in RFC 1305, with the exception of the Reference Identifier field described below. For SNTP client messages, most of these fields are zero or initialized with pre-specified data. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI | VN |Mode | Stratum | Poll | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Dispersion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reference Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originate Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receive Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transmit Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier (optional) (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Message Digest (optional) (128) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure: NTP/SNTP Packet Header Requirement and Specifications for an Unicast SNTP Client SNTP clients should be used only at the boundaries of the synchronization subnet. Another requirement for working of SNTP clients is that it should operate only at highest stratum of the subnet and in the network configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. Each client should be independent of each other in a network. SNTP servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no other source of synchronization other than a reliable radio clock or telephone modem is available. Broadcast servers should respond to client unicast requests, as well as send unsolicited broadcast messages. Broadcast clients may send unicast requests in order to measure the network propagation delay between the server and client and then continue operation in listen-only mode. However broadcast server may choose not to respond to unicast requests, so unicast clients should be prepared to abandon the measurement and assume a default value for the delay. Client requests are normally sent at intervals depending on the frequency tolerance of the client clock and the required accuracy. However, under no conditions should requests be sent at less than one minute intervals. Although setting the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format is not necessary in a conforming client implementation, it is highly recommended in unicast and manycast modes. This allows a simple calculation to determine the propagation delay between the server and client and to align the system clock generally within a few tens of milliseconds relative to the server. In addition, this provides a simple method for verifying that the server reply is in fact a legitimate response to the specific client request and thereby for avoiding replays. In broadcast mode, the client has no information to calculate the propagation delay or to determine the validity of the server, unless one of the NTP authentication schemes is used. The SNTP client should use UDP port number 123 in the UDP Destination Port field for client request messages. The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages. RFC 2030 specifications required both the source and destination ports to be 123. This allow the identification of particular client implementations (which are now allowed to use unreserved port numbers, including ones of their choosing) and to attain compatibility with Network Address Port Translation (NAPT) described in RFC 2663 [SRI99] and RFC 3022 [SRI01]. Designing and developing an SNTP client Unicast clients must be provided with the designated server name or address. If a server name is used, the address of one of more DNS servers must be provided. Multicast servers and anycast clients must be provided with the TTL and local broadcast or multicast group address. Anycast servers and multicast clients may be configured with a list of address-mask pairs for access control, so that only those clients or servers known to be trusted will be used. These servers and clients must implement the IGMP protocol and be provided with the local broadcast or multicast group address as well. There are several scenarios which provide automatic server discovery and selection for SNTP clients with no pre-specified configuration, other than the IP address and subnet mask or OSI NSAP address. For an IP subnet or LAN segment including a fully functional NTP server, the clients can be configured for multicast mode using the local broadcast address. The same approach can be used with other servers using the multicast group address. In both cases, provision of an access control list is a good way to insure only trusted sources can be used to set the local clock. Following points should be taken care of while designing a SNTP client: 1. When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply. 2. When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply. 3. The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request. 4. The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields is 0 or the Mode field is not 4 (unicast) or 5 (broadcast). 5. A truly paranoid client can check that the Root Delay and Root Dispersion fields are each greater than or equal to 0 and less than infinity, where infinity is currently a cozy number like one second. This check avoids using a server whose synchronization source has expired for a very long time SNTP Client Program int _tmain(int argc, _TCHAR* argv[]) { int const iGMTDiff = (1 * 60); // Number of minutes local time differs from UTC. Here it is UK time GMT +1 WORD wVersionRequested; WSADATA wsaData; int iError; //Load the WinSock version 2.2 wVersionRequested = MAKEWORD( 2, 2 ); //Startup WinSock service iError = WSAStartup( wVersionRequested, &wsaData ); if ( iError != 0 ) { printf( " Failed to load WinSock DLL" ); return -1; } //Create a Data gram socket. SOCKET hSocket = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP ); //IPPROTO_UDP ); if ( hSocket == INVALID_SOCKET ) { printf( " Failed to create socket" ); WSACleanup(); return -1; } //Get the Time server IP address char szTimeServer[] = "time-b.nist.gov"; //Time server hostent* remoteHost = gethostbyname( szTimeServer ); if ( remoteHost == NULL ) { printf( " Failed to get remote server IP address." ); closesocket( hSocket ); WSACleanup(); return -1; } char* pRemoteHopstIP = inet_ntoa (*(struct in_addr *)*remoteHost->h_addr_list); sockaddr_in addrRemoteHost; addrRemoteHost.sin_family = AF_INET; addrRemoteHost.sin_addr.s_addr = inet_addr( pRemoteHopstIP ); addrRemoteHost.sin_port = htons(123); //RFC 2030 Time server Port number (123) //Connect to the Time server if ( connect( hSocket, (SOCKADDR*) &addrRemoteHost, sizeof( addrRemoteHost ) ) == SOCKET_ERROR ) { printf( " Failed to connect with the Time server." ); closesocket( hSocket ); WSACleanup(); return -1; } //Create the TIME packet BYTE NTPPacket[48]; memset( NTPPacket, 0, sizeof( NTPPacket ) ); NTPPacket[0] = 0x1B; //Get the current time in seconds from 1st January 1900. COleDateTime dtStart( 1900, 1, 1, 0, 0, 0 ); COleDateTime dtCurrent = COleDateTime::GetCurrentTime(); COleDateTimeSpan timeSpan = dtCurrent - dtStart; //Set only the seconds.. unsigned long ulMilSecond = (unsigned long) timeSpan.GetTotalSeconds(); int iOffset = 40; for ( int i = 3; i >= 0; i-- ) { NTPPacket[ iOffset + i ] = (BYTE) ( ulMilSecond % 256 ); ulMilSecond /= 256; } //Send the dummy packet to the Time server. //Socket connected to the server, so use send instead of sendto int iBytesSend = send( hSocket, (char*) NTPPacket, sizeof(NTPPacket), 0); if ( iBytesSend > 0 ) //Successfully sent { int iSendAddSize = sizeof( addrRemoteHost ); //Read Time from the server. iError = recvfrom( hSocket, (char*) NTPPacket, sizeof( NTPPacket ), 0, (SOCKADDR*) &addrRemoteHost, &iSendAddSize ); if ( iError > 0 ) { printf( " Reply received from Time server." ); //Read successful. Set the time if ( ( NTPPacket[0] & 0x07 ) == 0x04 ) { //Valid response from Time server unsigned long uLongTimeInSecond = ( NTPPacket[40] Read More