Операции клиента SNTP
Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.
Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp. В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.
Рекомендуется чтобы клиенты использовали последнюю версию, которую поддерживает выбранный сервер.
Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.
Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток.
Таблица 4.4.16.5. Типы временных меток
| Имя временной метки | ID | Когда генерируется |
| Originate Timestamp (исходная метка) | T1 | Время отправки запроса клиента |
| [ZEBR_TAG_td style=text-align:center>T2 | Время получения запроса сервером | |
| Transmit Timestamp (метка посылки) | T3 | Время посылки отклика сервером |
| Destination Timestamp (метка назначения) | T4 | Время получения отклика клиентом |
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы “Отклик” и “Мультикаст”. Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой “Игнорируется”, зависит от конкретной реализации программы.
Таблица 4.4.16.6. Операции клиента и значения полей заголовка
| Имя поля | Уникаст/Эникаст | Мультикаст | |
| Запрос | Отклик | ||
| LI | 0 | 0-2 | 0-2 |
| VN (номер версии) | 1-4 | копируется из запроса | 1-4 |
| Режим | 3 | 4 | 5 |
| Слой | 0 | 1-14 | 1-14 |
| Запрос | 0 | Игнорируется | Игнорируется |
| Точность | 0 | Игнорируется | Игнорируется |
| Root Delay | 0 | Игнорируется | Игнорируется |
| Root Dispersion | 0 | Игнорируется | Игнорируется |
| Reference Identifier | 0 | Игнорируется | Игнорируется |
| Reference Timestamp | 0 | Игнорируется | Игнорируется |
| Originate Timestamp | 0 | (смотри текст) | Игнорируется |
| Receive Timestamp | 0 | (смотри текст) | Игнорируется |
| Transmit Timestamp | (смотри текст) | не равно нулю | не равно нулю |
| Аутентификатор | опционно | опционно | опционно |
