Известны ли Вам реализации NTP протокола на .NET языках с открытым кодом? Существут SNTP клиент на C#, однако упрощенный протокол не позволяет получить разницу во времени между двумя машинами с точностью выше чем 1 секунда.
Подозреваю, что в локальной сети можно поднять NTP-сервер и синхронизировать с ним целевые машины. Однако, это не всегда осуществимо.
p.s. Простите, что не в тему

Это сообщение отредактировал(а) Avashah - 23.6.2009, 15:29

Мне неизвестны, однако это не значит, что их нету   
Но точно есть на С
Вполне осуществимо, сервер можно запустить самому. А вот конектится к удаленным NTP серверам явно не всегда осуществимо, может банально не быть доступа в Inet

Не осуществимо в том смысле, что клиент не допустит установку NTP сервера. А на счет интернета - я так понял, что для синхронизации времени в локальной сети с одной из машин внутри той же сети, интерент и не нужен.
 
Если есть ссылка, то было бы просто супир!

Но запуск программы он допустит? NTP сервер вполне можно сделать программой. Можно его сделать и не сервером - ведь нужно всего лишь получить точную разницу часов на 2х машинах. NTP протокол (и сорцы сервера и клиента) вполне подойдут
Нужен сервер. C# клиент, на который была ссылка, использовал сервера из Интернета

 http://www.ntp.org/

По поводу структуры отловленного пакета: вот здесь сказано, что "Для выделения границ блоков принятых данных BPF снабжает их заголовком, содержащим время приема и размер блока, а также концевиком для синхронизации блоков данных." То же самое справедливо и для NDIS? Играет ли это какю-либо роль при сравнении уходящего/приходящего пакета? Я имею ввиду, что WinPcap при генерации события отправки/получения пакета передает в pcap_handler заголовок, добавляемый драйвером захвата, и сам пакет (целиком или фрагмент?). Так входит ли во второй параметр тот самый "концевик"? Это конечно напрямую зависит от того, передается ли в callback процедуру пакет целиком или фрагментарно. 
Как Вы думаете, разумно ли сравнивать пакеты по их CRC-сумме? 

Он может получать время с любой доступной машины, как в локальной сети, так и в Internet, лишь бы был открыт 123-й порт. В этом исходниках этого клиента есть несколько проблем, но они решаемы. Проблема в том, что он не дает желаемой точности 

Да, именно так. Однако, откровенно говоря, С/С++ мне практически незнакомы. Начинал с Delphi, теперь перешел на C#. А под .Net найти открытой реализации NTP клиента пока не удалось.

Это сообщение отредактировал(а) Avashah - 25.6.2009, 10:37

Пакет целиком, с Ethernet заголовком, но без CRC поля.
Пакет целиком
Если только вы ее сами посчитаете

Вам не нужна 'любая' машина, вам нужно засинхронизовать 2 свои машины. Конечно можно засинхронизовать обе машины с 3й в сети, но тогда на машинах нужны клиенты, встроенные в систему, что бы они синхронизировали именно системное время. Кроме того, 123 порт должен не просто 'быть открытым', на нем должен работать NTP сервер
Сам NTP дает гораздо большую точность, чем 1секунда.
Как только MS ядро ОС на .net напишет, так сразу   

Ну вот смотрите: вышеуказанный клиент, реализующий SNTP протокол, может получить разницу во времени с любой машины, по крайней мере в локальной сети, если она доступна. Т.е. видимо для этого достаточно стандартных средств Windows (возможно, 123 порт слушает служба синхронизации веремни). Никакого сервера там устанавливать не нужно для этого. С клиентом, реализующим NTP протокол, я полагаю, дело обстоит сложнее. Без установки сервера NTP на той машине, с которой будем синхронизироваться, не обойдешься. Но это так, к слову. Я уже понял, что написание NTP клиента под .net весьма проблематично, как и поиск исходников. Остается, либо брать готовое ядро на C/C++ и использовать его, либо пользоваться готовым софтом для синхронизации времени. Один вариант я уже нашел, но он как минимум не очень удобен. В любом случае, спасибо за консультацию!

Да действительно. Сервер там уже есть (живет в w32time.dll в system32)
Уже стоит
Проще. Нам не надо синхронизировать системные часы, поэтому клиент не обязан быть частью системы - мы можем его включить в состав своей программы
Он уже есть

Угу

На сайте разработчиков отдельно не выкладываются ни исходники ядра, ни само ядро NTP клиента (в виде библиотеки, например). Исходя из моих скромных знаний С, могу предположить, что посылку запроса и получение ответа (функции sendrequest и getresponce соответственно) достаточно затруднительно отделить от реализации ntpd. Поправьте меня, если я ошибаюсь.
Кстати, ntpdate не может получить разницу во времени, если на предполагаемом сервере времени не запущен ntpd. Получается, стандартных средств (w32time.dll) недостаточно для ответа? 

Это сообщение отредактировал(а) Avashah - 26.6.2009, 17:04

На сайте разработчиков выложены ИСКЛЮЧИТЕЛЬНО исходники этого всего
 http://www.eecis.udel.edu/~ntp/ntp_spool/n...tp-4.1.2.tar.gz

Соответствующие RFC читать не пробовали? На сайте есть ссылки

Я не знаю, какую часть функциональности реализует w32time.dll, надо смотреть MSDN

А вот такая деталь: в протоколе TCP фигурирует механизм квитирования - "отчет о доставке" каждого кадра, входящего в TCP пакет.  В WinPcap же событие прихода пакета, как я понял, генерируется для всего пакета (собранного из кадров), а не для каждого кадра в отдельности. Соответственно, на каждое событие отправления TCP пакета будет приходиться несколько событий получения "отчета о доставке", ведь каждая квитанция идет отдельным пакетом.  Верно?
p.s. хотя вероятно неверно. При использовании протокола TCP поток байт, подлежащих передаче, делится на сегменты. Каждый сегмент передается отдельным TCP пакетом (которые и будут "отловлены" WinPcap) со своим номером последовательности (где номер последовательности - это число уже переданных байтов из исходной последовательности + 1), а так же набором флагов SYN и ACK. При получении пакета получатель (Б) информирует отправителя (А) о получении. Это происходит посредством отправки ответного TCP пакета (возможно после обработки исходного, а так же ответ получателя Б сам может являться новым запросом каких-то данных у точки А), где указывается номер подтверждения, равный общему числу полученных байт данных от точки А... Каша в голове. Так что же выступает подтверждением доставки? Если в ответ на пакет из А в Б с номером последовательности N, получаем пакет из Б в А с номером подтверждения > N. Так? Причем, совершенно необязательно, что подтверждение придет сразу же. Так?
При помощи WinPcap мы сможем отследить и запрос и подтверждение. Но сможем ли мы по этим двум пакетам определить (хотя бы приблизительно) время, затраченное на доставку? Ведь на два запроса может придти одно подтверждение.

Это сообщение отредактировал(а) Avashah - 7.7.2009, 12:54

Угу
Для Ethernet пакета, а не TCP пакета. WinPcap работает на более низком уровне, чем даже голый IP (не говоря уже об TCP)
Нет. Квитанция будет 1 штука (максимум) на весь TCP пакет, или даже меньше - TCP поддерживает отправку одной квитанции на несколько пакетов сразу. Кроме того, насколько я помню, в TCP квитанции могут быть инкапсулированны в пакеты данных (хотя могу и ошибаться, кто помнит - поправьте)

Не успел отредактировать, уже ответ Спасибо. Но вопросы остаются. И добавился еще один - всегда ли квитанция приходит TCP пакетом?

Собственно ответный пакет и выступает. Точнее номер подтвержденного сегмента.
Так
Так
Да.
Только приблизительно. Мы можем получить одно подтверждение на несколько пакетов. Времена на их доставку будут разные.
Да. Можно считать, что время на доставку равно времени получения подтверждения минус время отправки пакета с сегментом. Причем пакетов с сегментами может быть несколько, а пакет с подтверждением - один.

Всегда, если только пакет не потерялся по дороге (тогда квитанции не будет)

Спасибо. Все больше склоняюсь к тому, что задача общего решения не имеет.