Протокол SNTP Опции

[Pridnya]

Здравствуйте, товарищи!

Использую стек lwIP 1.3.2, протокол SNTP (за основу взят sntp из архива contrib-1.4.1). Заполняю структуру sntp_msg,

Код

struct sntp_msg {
PACK_STRUCT_FIELD(u8_t  li_vn_mode);
PACK_STRUCT_FIELD(u8_t  stratum);
PACK_STRUCT_FIELD(u8_t  poll);
PACK_STRUCT_FIELD(u8_t  precision);
PACK_STRUCT_FIELD(u32_t root_delay);
PACK_STRUCT_FIELD(u32_t root_dispersion);
PACK_STRUCT_FIELD(u32_t reference_identifier);
PACK_STRUCT_FIELD(u32_t reference_timestamp[2]);
PACK_STRUCT_FIELD(u32_t originate_timestamp[2]);
PACK_STRUCT_FIELD(u32_t receive_timestamp[2]);
PACK_STRUCT_FIELD(u32_t transmit_timestamp[2]);
};

вставляю в неё свою метку времени originate_timestamp[] и отправляю её NTP-серверу (служба времени Windows), в ответ получаю такую же структуру с четырьмя метками времени. В файле sntp.c (из архива contrib-1.4.1) есть функция

Код

/* SNTP processing of received timestamp  */
static void sntp_process(u32_t *receive_timestamp)
{
  /* convert SNTP time (1900-based) to unix GMT time (1970-based)
   * @todo: if MSB is 1, SNTP time is 2036-based!
   */
  time_t t = (ntohl(receive_timestamp[0]) - DIFF_SEC_1900_1970);

#if SNTP_CALC_TIME_US
  u32_t us = ntohl(receive_timestamp[1]) / 4295;
  SNTP_SET_SYSTEM_TIME_US(t, us);
  /* display local time from GMT time */
  LWIP_DEBUGF(SNTP_DEBUG_TRACE, ("sntp_process: %s, %"U32_F" us", ctime(&t), us));

#else /* SNTP_CALC_TIME_US */

  /* change system time and/or the update the RTC clock */
  SNTP_SET_SYSTEM_TIME(t);
  /* display local time from GMT time */
  LWIP_DEBUGF(SNTP_DEBUG_TRACE, ("sntp_process: %s", ctime(&t)));
#endif /* SNTP_CALC_TIME_US */
}

Из этого кода следует, что метка времени receive_timestamp[] (момент времени, когда NTP-сервер получил запрос клиента) переводится из NTP timestamp в UnixTime и далее используется клиентом как "время сервера" (эталонное), при этом никак не учитываются два параметра из протокола SNTP (RFC1769 SNTP v3) - циклическая задержка и смещение времени (см.скриншот). Это авторы кода так упростили себе задачу и почему они так сделали? И как учесть циклическую задержку и смещение?

Сообщение отредактировал Pridnya - Dec 12 2016, 06:22

Эскизы прикрепленных изображений

 

[Pridnya]

Не ожидал такой лажи от создателей примеров lwIP contrib-1.4.1, sntp.c.
Клиент получает структуру (ответ на запрос с метками времени):

CODE

#define SNTP_OFFSET_ORIGINATE_TIME 24
#define SNTP_OFFSET_RECEIVE_TIME 32
#define SNTP_OFFSET_TRANSMIT_TIME 40
...
struct sntp_msg {
PACK_STRUCT_FIELD(u8_t li_vn_mode);
PACK_STRUCT_FIELD(u8_t stratum);
PACK_STRUCT_FIELD(u8_t poll);
PACK_STRUCT_FIELD(u8_t precision);
PACK_STRUCT_FIELD(u32_t root_delay);
PACK_STRUCT_FIELD(u32_t root_dispersion);
PACK_STRUCT_FIELD(u32_t reference_identifier);
PACK_STRUCT_FIELD(u32_t reference_timestamp[2]); // Время синхронизации сервера.
PACK_STRUCT_FIELD(u32_t originate_timestamp[2]); // Метка времени клиента (для проверки ответа на свой запрос)
PACK_STRUCT_FIELD(u32_t receive_timestamp[2]); // Время получения запроса сервером
PACK_STRUCT_FIELD(u32_t transmit_timestamp[2]); // Время на момент отправки ответа сервером.
};
...
static void sntp_recv(void *arg, struct udp_pcb* pcb, struct pbuf *p, ip_addr_t *addr, u16_t port)
{
...
// Создается новый массив для полученной эталонной метки времени.
u32_t receive_timestamp[SNTP_RECEIVE_TIME_SIZE];
...
/*И в новый массив копируется метка "Время получения запроса сервером", при этом сколько времени
сервер потратил на обработку запроса никого не интересует. А другие SNTP-клиенты копируют "Время на момент отправки ответа сервером",
в этом случае задержка сервера не имеет значения.*/
pbuf_copy_partial(p, &receive_timestamp, SNTP_RECEIVE_TIME_SIZE * 4, SNTP_OFFSET_RECEIVE_TIME);

// Далее следует установка времени.
sntp_process(receive_timestamp);

И еще одинаковые длинные имена используют внутри структуры и во временном массиве receive_timestamp[].
Берут не ту метку и заведомо ухудшают точность. И на этом нам предлагается учиться.

[jcxz]

И еще одинаковые длинные имена используют внутри структуры и во временном массиве receive_timestamp[].
Берут не ту метку и заведомо ухудшают точность. И на этом нам предлагается учиться.

А что Вы хотите? "Дарёному коню..." Напишите своё - SNTP - простой протокол.

[Ruslan1]

Эх, у меня исходники sntp только для Майкрочипа. А тут просят SNTP именно для АРМов (раз в этом разделе тему создали), значит мои сишные файлы не подойдут.

[jcxz]

Эх, у меня исходники sntp только для Майкрочипа. А тут просят SNTP именно для АРМов (раз в этом разделе тему создали), значит мои сишные файлы не подойдут.

А что - есть SNTP для пиков, а есть - для ARM-ов???
Я думаю в IEEE этого ещё не знают. Надо им сообщить срочно. Пусть внесут правки в стандарт

[Pridnya]

А что Вы хотите? "Дарёному коню..." Напишите своё - SNTP - простой протокол.

Автор SNTP-клиента

SNTP client module (contrib-1.4.1\apps\sntp)
Author: Simon Goldschmidt (lwIP raw API part).

он же является автором многочисленных правок LwIP-стека, его имя присутствует в файлах. И я ожидал, что это толковый товарищ, а оказывается за ним все нужно проверять. А вообще, я пишу свою реализацию, хочется учесть недостатки существующих SNTP-клиентов.

Эх, у меня исходники sntp только для Майкрочипа. А тут просят SNTP именно для АРМов (раз в этом разделе тему создали), значит мои сишные файлы не подойдут.

Я вроде не просил. И с SNTP-клиентом знаком. В последней версии MLA Microchip дает исходники простенького такого клиента.

mla\v2016_08_08\framework\tcpip\sntp.h
mla\v2016_08_08\framework\tcpip\src\sntp.c

Вот мое мнение по этому поводу. Меня интересует, а как в MPLAB Harmony c SNTP-клиентом дела?

А что - есть SNTP для пиков, а есть - для ARM-ов???
Я думаю в IEEE этого ещё не знают. Надо им сообщить срочно. Пусть внесут правки в стандарт

SNTP-клиент - вещь абстрактная, он не знает о существовании микроконтроллеров, не знает на какой архитектуре запущен. Но SNTP-клиент для PIC-ов есть и выложен он в mla\v2016_08_08\framework\tcpip\src\sntp.c. Но он совсем простой, т.к. авторы предполагали, что он будет работать даже на PIC18. Но после PIC18 есть же еще PIC24, PIC32MX и PIC32MZ, и не совсем правильно для PIC32 использовать клиент со времен PIC18 (те же исходникик).
Если архитектура микроконтроллера позволяет, то можно и улучшить SNTP-клиент, повысить точность.
PS: Полно простых реализаций SNT-клиентов, которые не проверяют, когда последний раз синхронизировался сам сервер, не вставляют в запрос свою метку времени, не учитывают субсекунды (до секунд и хватит), не учитывают время задержки, а ведь SNTP позволяет получить точность 1-50 мс от сервера в Интернете и до 0,2 мс от сервера в локальной сети. И тоже называются SNTP-клиентами.

[Ruslan1]

Мда, мой шутка был понят не всеми, разъясню что имел в виду:
Тему создали в разделе "ARM", значит Топикстартеру нужно именно под АРМ. Я тоже не вижу разницы, но Топикстартеру виднее, раз именно тут спрошено.

Про "sntp для Майкрочип": я его писал уж наверное 7 лет как, тогда Майкрочип такого и не предлагал. Прочитал описание, посмотрел исходники из Линукса- и вперед на амбразуру.
Но если сейчас предлагают, да еще и "простенький" (а что там сложного может быть в отсылке запроса-разборке принятого?) - то и отлично, можно посмотреть, а не писать с нуля.