Добрый вечер.
Задача заключается в измерении производительности ряда протоколов (например TCP, UDP, ICMP, SNMP и др... желательно 3-4, выбор произвольный), определении зависимости размера пакета от времени передачи, т.е. необходима утилита, которая меряла бы время на передачу информации по средством различных протоколов.
Может быть кто-то с таким сталкивался или у кого-то есть наброски по реализации...?
Заранее благодарен.
10.04.07 22:26: Перенесено из '.NET'
Сравнение производительности протовоколов
От:
Аноним
Дата:
05.01.07 19:02
Оценка:
Сначала определись с протоколом или хотя бы с его видом. TCP подразумевает гарантированную доставку, и предназначен для передачи большого количесвта информации (не зря ведь умные дядьки его придумали). UDP это не гарантированная доставка, поэтому он и быстрее. Каждый протокол имеет свою направленность. Я бы не стал по ICMP передавать здоровый файл. Ну разве что управляющие команды...
Могу в принципе накидать. Надо две консольные утилитки, одна отсылает пакеты, в пакете есть просто левая инфа, и есть поле с временем создания пакета. А на приемной стороне ты принимаешь пакет, анализируешь время отправления, и делаешь разницу с текущим временем. Примерно получишь время прохзождения пакета. Повторив эксперимент раз так тысячу, усредни значение. Реализуется за пару часов.
Удачи
Тот кто употребляет выражение "Легче, чем отнять леденец у ребенка" вряд ли когда-нибудь пытался это сделать
Здравствуйте, CrazyDog, Вы писали:
CD>Сначала определись с протоколом или хотя бы с его видом. TCP подразумевает гарантированную доставку, и предназначен для передачи большого количесвта информации (не зря ведь умные дядьки его придумали). UDP это не гарантированная доставка, поэтому он и быстрее. Каждый протокол имеет свою направленность. Я бы не стал по ICMP передавать здоровый файл. Ну разве что управляющие команды... CD>Могу в принципе накидать. Надо две консольные утилитки, одна отсылает пакеты, в пакете есть просто левая инфа, и есть поле с временем создания пакета. А на приемной стороне ты принимаешь пакет, анализируешь время отправления, и делаешь разницу с текущим временем. Примерно получишь время прохзождения пакета. Повторив эксперимент раз так тысячу, усредни значение. Реализуется за пару часов.
Так точное время не получишь Для получения времени прохождения пакета неходимо воспользоваться алгоритмом пинга:
одна сторона передает пакеты со временной меткой (например с системным временем) и ждет их назад, а вторая сторона
тупо заворачивает обратно все пришедшие пакеты.
Со скоростью передачи данных алгоритм другой. Например, приложение создает два потока (для передачи и для приема),
запускается на 2-х компьютерах, соединяется само с собой, и принимает/передает энное кол-во инфы.
Поделив объём на время получим скорость.
Здравствуйте, CrazyDog, Вы писали:
CD>Я бы не стал по ICMP передавать здоровый файл. Ну разве что управляющие команды...
Первый же МЭ с функцией IDS тебя зарежет, ибо ICMP описан полностью, никаких шаг врпаво, шаг влево. Это чисто служебный протокол, использовать его в приложениях не надо никогда.
Здравствуйте, R0man, Вы писали:
R>Задача заключается в измерении производительности ряда протоколов (например TCP, UDP, ICMP, SNMP и др... желательно 3-4, выбор произвольный), определении зависимости размера пакета от времени передачи, т.е. необходима утилита, которая меряла бы время на передачу информации по средством различных протоколов.
Протокол вещь такая, что от конкретного железа зависит весьма слабо.А утилита(любая) скорей определит производительность сети функциклирующей по заданному протоколу, если задача в этом, то постановка вопроса немного не корректна. У Олиферов и Таненбаума вопросы производительности и эффективности изложены не плохо.
Здравствуйте, tartilla, Вы писали:
T>Здравствуйте, R0man, Вы писали:
R>>Задача заключается в измерении производительности ряда протоколов (например TCP, UDP, ICMP, SNMP и др... желательно 3-4, выбор произвольный), определении зависимости размера пакета от времени передачи, т.е. необходима утилита, которая меряла бы время на передачу информации по средством различных протоколов.
T>Протокол вещь такая, что от конкретного железа зависит весьма слабо.А утилита(любая) скорей определит производительность сети функциклирующей по заданному протоколу, если задача в этом, то постановка вопроса немного не корректна. У Олиферов и Таненбаума вопросы производительности и эффективности изложены не плохо.
Очень даже зависит и от железа и от софта и от структуры сети и от помеховой обстановки и от протоколов канального и физического уровней. "Утилита, которая меряет время на передачу информации по средством различных протоколов(например TCP, UDP, ICMP, SNMP и др...)" покажет картину для участка сети (направления передатчик-приемник) в данный момент времени. Эта картина может меняться во времени.
V>Очень даже зависит и от железа и от софта и от структуры сети и от помеховой обстановки и от протоколов канального и физического уровней.
Очень даже зависит что? Производительность сети или протокола? Протокол-это всего лишь правила обмена инфой. И его "производительность" скорей будет отношением информационного траффика к общему согласно рекомендации соответствующего номера. А ежиль канальный уровень CRC попутал и физический никак из бублика звездочку не сделает дык тогда не протокол плохой, а канал (и сеть в целом) никакой. И решение о запуске вторичной сети немного глупое.
> "Утилита, которая меряет время на передачу информации по средством различных протоколов(например TCP, UDP, ICMP, SNMP и др...)" покажет картину для участка сети (направления передатчик-приемник) в данный момент времени.
Для любых равных физических условиях соотношение будет фиксировано, но численные значения конкретных реализаций разные, а если важны конкретные условия см выше — Это производительность конфигурации сети. а не протокола. А ежель кто фильму начнет качать в разгар измерения, то мы соверешенно точно скажем, что TCP гораздо бустрее UDP и пусть злые языки нас не парят
>Эта картина может меняться во времени.
Будь я проектировщик я б сказанул "юзаем вчерашний TCP, а то сегодняшний больно глючит"