Пытаюсь получить ответ от NTP-сервера в следующем коде (иницализацию и проверку ошибок для краткости не привожу):

struct hostent *server = gethostbyname("ntp3.ntp-servers.net");
struct sockaddr_in serveraddr;
memset((char *)&serveraddr, 0, sizeof(serveraddr));
serveraddr.sin_family = AF_INET;
serveraddr.sin_addr.S_un.S_un_b.s_b1 = server->h_addr[0];
serveraddr.sin_addr.S_un.S_un_b.s_b2 = server->h_addr[1];
serveraddr.sin_addr.S_un.S_un_b.s_b3 = server->h_addr[2];
serveraddr.sin_addr.S_un.S_un_b.s_b4 = server->h_addr[3];
serveraddr.sin_port = htons((u_short)123);

serverlen = sizeof(serveraddr);
n = sendto(sockfd, buf, strlen(buf), 0, (const sockaddr*)&serveraddr, serverlen);
n = recvfrom(sockfd, buf, strlen(buf), 0, (sockaddr*)&serveraddr, &serverlen);

Здесь — висим! (Если не поставить timeout, то висим вечно.)
Вопрос в том, должен ли что-нибудь ответить сервер или я что-то накосячил?
Спасибо.

Здравствуйте, Kuzya_vl, Вы писали:

K> Вопрос в том, должен ли что-нибудь ответить сервер или я что-то накосячил?

Скажем так. Сервер отвечать не обязан (особенно, если пакет неверный). Помимо всего прочего — UDP пакет мог и не дойти. По этому отваливание по таймауту должно быть обязательно реализовано.

Здравствуйте, Anton Batenev, Вы писали:

AB>Скажем так. Сервер отвечать не обязан (особенно, если пакет неверный). Помимо всего прочего — UDP пакет мог и не дойти. По этому отваливание по таймауту должно быть обязательно реализовано.
1. Будем счтитать что пакет правильный (byte data[48]; data[0] = 27; (leap indicator=0; version number=3;(Version4) Mode=3;(Clinet) последние 8 байт-локальное время).
2. Как сделать чтобы пакет гарантированно дошел?

K_>n = sendto(sockfd, buf, strlen(buf), 0, (const sockaddr*)&serveraddr, serverlen);
K_>n = recvfrom(sockfd, buf, strlen(buf), 0, (sockaddr*)&serveraddr, &serverlen);[/ccode]
K_>Здесь — висим! (Если не поставить timeout, то висим вечно.)
K_>Вопрос в том, должен ли что-нибудь ответить сервер или я что-то накосячил?
K_>Спасибо.
В подробности ntp не вникал, но пробежавшись по rfc5905 — это бинарный протокол. Откуда и зачем ваще strlen?

K_>2. Как сделать чтобы пакет гарантированно дошел?
никак

Здравствуйте, ononim, Вы писали:

O>В подробности ntp не вникал, но пробежавшись по rfc5905 — это бинарный протокол. Откуда и зачем ваще strlen?
Спасибо.

n = sendto(sockfd, (char*)buf, sizeof(buf), 0, (const sockaddr*)&serveraddr, serverlen);
n = recvfrom(sockfd, (char*)buf, sizeof(buf), 0, (sockaddr*)&serveraddr, &serverlen);

Какая то маленькая описка на весь день выбила из колеи!!!

Здравствуйте, Kuzya_vl, Вы писали:

K> 1. Будем счтитать что пакет правильный (byte data[48]; data[0] = 27; (leap indicator=0; version number=3;(Version4) Mode=3;(Clinet) последние 8 байт-локальное время).

ОК. Просто поведение очень похоже на то, что NTP сервер отбрасывает пакет, т.к. считает его невалидным.

K> 2. Как сделать чтобы пакет гарантированно дошел?

Никак, это особенность протокола UDP.

Я проверил сервер:

$ /usr/sbin/ntpdate -d ntp3.ntp-servers.net
22 Nov 17:46:31 ntpdate[30403]: ntpdate 4.2.4p8@1.1612 Fri Feb 26 14:32:45 UTC 2010 (1)
Looking for host ntp3.ntp-servers.net and service ntp
host found : n1.sigma.d6.hsdnsrv.net
transmit(88.147.254.232)
transmit(88.147.254.232)
receive(88.147.254.232)
transmit(88.147.254.232)
receive(88.147.254.232)
transmit(88.147.254.232)
receive(88.147.254.232)
transmit(88.147.254.232)
server 88.147.254.232, port 123
stratum 2, precision -20, leap 00, trust 000
refid [88.147.254.232], delay 0.06107, dispersion 8.00130
transmitted 4, in filter 4
reference time:    d276228f.07d16474  Tue, Nov 22 2011 17:30:55.030
originate timestamp: d276263a.79e4ee72  Tue, Nov 22 2011 17:46:34.476
transmit timestamp:  d276263a.7550b955  Tue, Nov 22 2011 17:46:34.458
filter delay:  0.00000  0.06657  0.06107  0.06523 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.002422 -0.00109 -0.00196
         0.000000 0.000000 0.000000 0.000000
delay 0.06107, dispersion 8.00130
offset -0.001092

22 Nov 17:46:34 ntpdate[30403]: adjust time server 88.147.254.232 offset -0.001092 sec

Т.е. сам сервер отвечает и корректно работает — проблема с огромной вероятностью в пакете или способе отсылки.