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 5]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996


NTP multicast addresses for IPv6 and OSI have yet to be determined. Multicast clients listen on the designated local broadcast address or multicast group address. In the case of local broadcast addresses, no further provisions are necessary. In the case of IP multicast addresses, the multicast client and anycast server must implement the Internet Group Management Protocol (IGMP) [DEE89], in order that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group addresses assigned by the IANA. Other than the IP addressing conventions and IGMP, there is no difference in server or client operations with either the local broadcast address or multicast group address.

It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value, in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only cooperating anycast servers in scope will reply to a client request. The engineering principles which determine the proper value to be used are beyond the scope of this document.


Anycast mode is designed for use with a set of cooperating servers whose addresses are not known beforehand by the client. An anycast client sends a request to the designated local broadcast or multicast group address as described below. For this purpose, the NTP multicast group address assigned by the IANA is used. One or more anycast servers listen on the designated local broadcast address or multicast group address. Each anycast server, upon receiving a request, sends a unicast reply message to the originating client. The client then binds to the first such message received and continues operation in unicast mode. Subsequent replies from other anycast servers are ignored.

In the case of SNTP as specified herein, there is a very real vulnerability that SNTP multicast clients can be disrupted by misbehaving or hostile SNTP or NTP multicast servers elsewhere in the Internet, since at present all such servers use the same IPv4 multicast group address assigned by the IANA. Where necessary, access control based on the server source address can be used to select only the designated server known to and trusted by the client. The use of cryptographic authentication scheme defined in RFC-1305 is optional; however, implementors should be advised that extensions to this scheme are planned specifically for NTP multicast and anycast modes.

< Пред.   След. >
Коммерческие вопросы
Технические вопросы
Запрос адреса 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