реализовал heartbeat для UDP. все работет.
но чисто в академических целях любопытно мониторить время этого heartbeat`а.
сейчас тупо отмечаю время отправки пакета и время прихода ответа на него и делю пополам.
но, думаю, это как-то неправильно...
подскажите, кто в теме.
спасибо.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
исходники ping.c открыты для изучения
да и в гугле всегда можно вбить
how to calculate rtt network
и зачитаться
это целая наука из которой каждый год изобретают новый алгоритм для tcp
Здравствуйте, niXman, Вы писали:
X>сейчас тупо отмечаю время отправки пакета и время прихода ответа на него и делю пополам. X>но, думаю, это как-то неправильно...
Неправильно. Делить измеренное время пинга безосновательно. В случае UDP, и других немаршрутизируемых протоколов, это не очевидно, но вот в случае TCP/IP всё встаёт на свои места: время достижения исходным пакетом адресата может существенно отличаться от времени достижения ответом отправителя. В этом случае половина времени ни о чём не говорит, а в случае передачи относительно больших объёмов данных (больше TCP Window) вообще бесполезна — имеет значение только полное время.
X>подскажите, кто в теме.
Я не то чтобы в теме, но про TCP читал и даже свои протоколы пытался инженерить (на основе TCP).
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, niXman, Вы писали:
X>реализовал heartbeat для UDP. все работет. X>но чисто в академических целях любопытно мониторить время этого heartbeat`а. X>сейчас тупо отмечаю время отправки пакета и время прихода ответа на него и делю пополам. X>но, думаю, это как-то неправильно...
А зачем ты его делишь пополам?
В принципе, с практической точки зрения интересно (и измеряемо) время путешествия пакета туда и обратно (round-trip time). ping печатает именно это время.
Здравствуйте, Философ, Вы писали:
Ф>Неправильно. Делить измеренное время пинга безосновательно. В случае UDP, и других немаршрутизируемых протоколов, это не очевидно, но вот в случае TCP/IP всё встаёт на свои места: время достижения исходным пакетом адресата может существенно отличаться от времени достижения ответом отправителя. В этом случае половина времени ни о чём не говорит, а в случае передачи относительно больших объёмов данных (больше TCP Window) вообще бесполезна — имеет значение только полное время.
Время прохождения пакета в одну сторону достаточно сложно измерить, да и практической ценности особой оно не имеет.
В TCP важен именно RTT (round-trip time) потому что:
1) быстрее RTT ответ не придет. Поэтому чтобы загрузить сеть полностью, надо слать, не дожидаясь подтверждения, столько, сколько при доступной скорости за время RTT пролезет, но нет смысла слать сильно больше
2) Если подтверждение не пришло за время RTT с некоторым запасом, то скорее всего, что-то потерялось по дороге, и есть смысл перепослать.
Здравствуйте, reversecode, Вы писали:
R>исходники ping.c открыты для изучения R>да и в гугле всегда можно вбить R>how to calculate rtt network R>и зачитаться R>это целая наука из которой каждый год изобретают новый алгоритм для tcp
если я все буду делать сам, с кем ты будешь общаться?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Pzz, Вы писали:
Pzz>А зачем ты его делишь пополам?
Pzz>В принципе, с практической точки зрения интересно (и измеряемо) время путешествия пакета туда и обратно (round-trip time). ping печатает именно это время.
в моей задаче трафик идет только в одну сторону — от клиента к серверу.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Философ, Вы писали:
Ф>Неправильно. В случае UDP, и других немаршрутизируемых протоколов, это не очевидно, но вот в случае TCP/IP всё встаёт на свои места
Простите, но вот за это "-1". Это какая-то люто неправильная терминология.
Ф>Я не то чтобы в теме, но про TCP читал и даже свои протоколы пытался инженерить (на основе TCP).
В общем случае транспортный протокол — TCP/UDP/etc. — на маршрутизацию пакета не влияет. В этом и суть разделения уровней.
Здравствуйте, niXman, Вы писали:
X>подскажите, кто в теме.
Посмотри как считают RTT в RTCP для SR/RR репортов. Тебе нужен 3550 рфс, ищи по "Example for round-trip time computation". Эта штука работает вполне сносно.
