Время прохождения пакета по сети

[lit-uriy]

При работе через ethernet нужно всё таки задействовать ICMP (как писалось выше).
Точности в ethernet'е не было и быть не может, особенно при хождении пакета чёрти где (GPRS).

Есть такая программа MTR (в Виндовозе WinMTR), попробуй ею посмотреть где шарахаются пакеты. Она маршрут рассказывает.

П.С. В сетевых технологиях,, я не силён. Но, вроде, управлять маршрутом нельзя.

[BRE]

Есть такая программа MTR (в Виндовозе WinMTR), попробуй ею посмотреть где шарахаются пакеты. Она маршрут рассказывает.

traceroute же.
И в linux и в венде есть из коробки.

[juvf]

да при чем здесь traceroute и ICMP?. Как задействовать ICMP? Задача стоит не в том, чтоб определить маршрут и время передачи пакета ICMP, что делает traceroute рассчитывая время по формуле (t_ТУДА+t_ОБРАТНО)/2. Нужно передать данные без метки времени. получатель должен с точностью до 10 мс вычислить время, в которое отправитель отправил (и это не пакет ICMP, это пакет конкретного приложения, например "Mobdus TCP/IP"). GPRS - ну конечно тут нет ни каких гарантий по времени. Но даже по земле нет. tracert показал время передачи 30 мс. Где-нибудь нагрузка на промежуточный сервер увеличится и время возрастёт. Или маршрут поменяется, или провайдер какой-нибудь сменится, или провайдер оборудование сменит - и всё, время ушло. Нее.... я уже понял

Точности в ethernet'е не было и быть не может

[BRE]

Насчет traceroute, я писал lit-uriy о том, что есть утилита, которой можно просмотреть маршрут из коробки и в linux и в венде.
Насчет того как определяется время в ICMP. При отсылке пакета 13, отправитель (А) фиксирует время отправки, получатель изменяет тип сообщения на 14 и вписывает время приема сообщения и время отправки его обратно.  При приеме ответа на стороне А, она может узнать реальное время прохождения пакета туда и обратно, используя три поля со штампами времени.
Как будет вести себя твоя сторона А (что она будет заносить в штампы времени) - вопрос, который интересно проверить. Возможно, будут значение с единицей в старшем разряде, что говорит о нестандартном значении времени.

[Igors]

Сижу думаю, в чём дело??? Вдруг, примерно через минуту Б получает " STATUSSTATUSSTATUSSTATUSSTATUSSTATUS". Т.е. все мои команды пришли разом. Получается первое слово пришло через минуту-две, последнее, через 10- 20 сек. А заказчик требует точность до 10 мс (описался в первом посте). О какой статистике и прогнозе может идти речь при таких задержках?

Не видно смысла посылать следующий пакет не получив подтверждения что предыдущий получен. Хотя бы потому что следующая посылка зависит от ответа, проще иметь подтверждение всегда.

Насчет 10 миллисекунд. Спорить с заказчиком не нужно, 10 так 10. Но надо четко пояснить ему что программа не отвечает за скорость передачи, за качество канала связи и.т.п. Программа посылает/принимает данные в/из какого-то порта - это ВСЕ. Разборки с маршрутизацией и др. - все это другая задача, которая, разумеется, должна оплачиваться отдельно.

Примечания: (может пригодится)

-при посылке/приеме больших данных в сокет буферирование так же важно для скорости как и при записи в файл.

- часто лучше сначала вылить посылаемый пакет в файл а затем этот файл лить в сокет

[juvf]

О!!! Подсказали приемлемый вариант решения. Можно у "глупого" запустить часы, (например замутить программные или поставить RTC) и синхронизировать их по NTP4.
http://ru.wikipedia.org/wiki/NTP

[niXman]

Вы адекватны?
Ваш пост?

были бы часыв точке А, вопросов бы не было. На самом деле нужно в Б зафиксировать событие произошедшее в А, но в часы есть только в Б.

[lit-uriy]

>>Вы адекватны?
Просто выхода другого нет, поэтому происходит модернизация.