Mobatime Systems: специалист в области разработки, производства и поставки приборов и систем единого времени - Главная страница   Предприятие Mobatime Group в России, первичные, вторичные часы, серверы времени: разработка, производство, продажа, техническая поддержка - Главная страница
Общая информация
Mobatime Systems
Наши новости
Термины и определения
О компании
Mobatime Group
Карта сайта
Коммерческие вопросы
Технические вопросы
Серийная продукция
Серверы времени
Сетевые интерфейсы
Первичные часы
Часовые станции
Стрелочные часы
Стрелочные часы для улицы
Цифровые часы
Цифровые часы для улицы
Интерфейсные модули
Текстовые информационные панели
Уникальная продукция
Арктическое исполнение
Фасадные часы
Городские часы
Интерьерные часы
Часы для чистых помещений
Место встречи
Уличные часы Петербурга
Бесплатные ресурсы
Часы на JavaScript
Часы на Flash
Публичный NTP сервер
Часы и здания
Солнечные часы
Все про часы
Mobatime Systems arrow Термины и определения arrow Протокол SNTP
Протокол SNTP Печать

D. Mills

University of Delaware

October 1996
[Page 6]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996


While not integral to the SNTP specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP multicast clients on the same subnet, while IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain.

In NTP Version 3, the reference identifier was often used to walk-back the synchronization subnet to the root (primary server) for management purposes. In NTP Version 4, this feature is not available, since the addresses are longer than 32 bits. However, the intent in the protocol design was to provide a way to detect and avoid loops. A peer could determine that a loop was possible by comparing the contents of this field with the IPv4 destination address in the same packet. A NTP Version 4 server can accomplish the same thing by comparing the contents of this field with the low order 32 bits of the originate timestamp in the same packet.
There is a small possibility of false alarm in this scheme, but the false alarm rate can be minimized by randomizing the low order unused bits of the transmit timestamp.

3. NTP Timestamp Format

SNTP uses the standard NTP timestamp format described in RFC-1305 and previous versions of that document. In conformance with standard Internet practice, NTP data are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left, or high-order, position. Unless specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0.

Since NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established. NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order can be set to 0.

It is advisable to fill the non-significant low order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic roundoff errors and as a means of loop detection and replay detection (see below). One way of doing this is to generate a random bitstring in a 64-bit word, then perform an arithmetic right shift a number of bits equal to the number of significant bits of the timestamp, then add the result to the original timestamp.

< Пред.   След. >
Коммерческие вопросы
Технические вопросы
Запрос адреса NTP сервера
Тел.: +7 (812) 677-82-84
Факс:+7 (812) 677-82-85
Новости от Google
Точное время
Переход на зимнее время
Топ-10 уникальных посетителей за 30 дней:

free counters
© 2006-2017, "Мобатайм Системс", 192148, Санкт-Петербург, ул. Седова, 46, тел.: +7 (812) 677-82-84, факс: +7 (812) 677-82-85