Russian Qt Forum
Ноябрь 01, 2024, 02:37 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2]   Вниз
  Печать  
Автор Тема: Время прохождения пакета по сети  (Прочитано 14756 раз)
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #15 : Декабрь 25, 2009, 10:35 »

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

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

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

Юра.
BRE
Гость
« Ответ #16 : Декабрь 25, 2009, 10:39 »

Есть такая программа MTR (в Виндовозе WinMTR), попробуй ею посмотреть где шарахаются пакеты. Она маршрут рассказывает.
traceroute же.
И в linux и в венде есть из коробки.
Записан
juvf
Программист
*****
Offline Offline

Сообщений: 570


Просмотр профиля
« Ответ #17 : Декабрь 25, 2009, 11:59 »

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

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

Сообщений: 11445


Просмотр профиля
« Ответ #19 : Декабрь 25, 2009, 12:39 »

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

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

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

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

- часто лучше сначала вылить посылаемый пакет в файл а затем этот файл лить в сокет
Записан
juvf
Программист
*****
Offline Offline

Сообщений: 570


Просмотр профиля
« Ответ #20 : Декабрь 25, 2009, 13:54 »

О!!! Подсказали приемлемый вариант решения. Можно у "глупого" запустить часы, (например замутить программные или поставить RTC) и синхронизировать их по NTP4.
http://ru.wikipedia.org/wiki/NTP
Записан
niXman
Гость
« Ответ #21 : Декабрь 25, 2009, 14:00 »

Вы адекватны?
Ваш пост?
Цитировать
были бы часыв точке А, вопросов бы не было. На самом деле нужно в Б зафиксировать событие произошедшее в А, но в часы есть только в Б.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #22 : Декабрь 25, 2009, 18:00 »

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

Юра.
Страниц: 1 [2]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.051 секунд. Запросов: 23.