maytonПосмотри как тут.

http://openmaniak.com/iperf.php

Вообще минимум параметров.
Ты там TCP пролистай, про UDP поищи.

я тут добавил только -w 3m - это размер буфера.

maytonОК. Я понял. Значит для клиентской части измерителя необходимо указывать -b

Но в этом варианте



была достигнута скорость 511 Mbits/sec при отправке пакетов по UDP.
Затестил на отправки 500 Мб. Моя посылалка в неразогнаном виде дала 830-840 :)

maytonНу значит твоё приложение как-то работает с UDP по другому.
Я в первом посте писал как работает. Первый пакет окна подтверждается. Окно 32 пакета.
maytonЯ-бы для начала создал идеальный тракт...
Надоело уже. выжал 80% и нормально. Это не 8% как было. Завтра еще затестю iperf`ом скорость через TCP, для сравнения, сразу не догадался.

maytonТолько не мучай меня загадками. Когда пишешь "Затестил на отправки" - я терзаюсь.
Чем затестил? Своим софтом?
Своим. Те же два компа, тоже самое направление передачи что и iperf`ом.
Условия почти одинаковые, в обоих случаях сетка была не нагружена.

Алгоритм не скрываю (но реализацию не дам, т.к. там еще много чего намешано, не выковырять).

Алгоритм такой: первый пакет описание сообщения (размер пакета, количество пакетов, контрольная сумма и т.п.), далее отправитель шлет окна фиксированного размера (начальное 8 пакетов) каждые 20 мс. В первом пакете окна устанавливает флаг запроса подтверждения. Получатель при получении окна с флагом отправляет подтверждение и в нем указывает список недостающих пакетов. Оправитель приняв подтверждение меняет окно (нет потерь окно+=окно/5+1, есть потери окно-=количество потеряных в окне). В случае запроса потерянных они сразу же высылаются в следующем окне. По результату получения всех пакетов получатель шлет подтверждение приема. Отправитель получив подтверждение останавливает отправку.
В случае быстрой доставки (локалка например) интервал не выдерживается, подтверждение первого пакета последнего отправленного окна сразу запускает отправку следующего.

Суть описал, но есть ньюансы реализации. Главное не вносить никакой синхронности (долго шел до осознания этой банальности). Я ее внес только для ускорения в локалке. Если прохождение пакета до получателя и обратно 50 мс, и при этом ждать подтверждения каждого окна, то эти 50 мс станут основным тормозом.

Почему именно так (из наблюдений):
1. Подтверждать первый пакет - обычно он не теряется, теряется хвост если слишком много пакетов не входит в буфер очередного шлюза.
2. Интервал 20 мс - долго думал, с одной стороны кривые часы (в XP шаг 10 мс), с другой квант времени выделяемый процессу виндовсом, с третьей разные скорости каналов (12 кбайт/с GPRS и гигабит в локалке), с четвертой потери на длинных окнах (в магистральных каналах на окне из 48 пакетов уже потери начинаются). Вобщем выбрал максимум 32 пакета за 20 мс (2,3 мбайт/с), минимум 1 (72,5 кбайт/с). Ктати это и привело к поднятию темы, т.к. за 20 мс не уходило 32 пакета.
3. Размер пакета - ставлю флаг запрета дефрагментации пакета (IP_DONTFRAGMENT) и при подключении шлю до сервера проверки разного размера (у серверов в инете 1472 гарантированно), максимально подтвержденная - максимальный размер пакета (в диапазоне 1372-1472). Отправка данных размером минимума из максимумов отправителя и получателя.

Вобщем неплохо работает как для быстрых и медленных каналов, так и для очень далеких точек на быстром канале.

maytonЧто у тебя за трафик? Что за алгоритм - непонятно. Может тебе не нужен UDP ?

Тут писал 17343378

Вообще это распределенная система обмена сообщениями любого размера. Шина данных. Без какого-либо центрального сервера. Т.е. есть группа серверов готовых соединить двух абонентов, при том что падение одного-двух серверов никак не влияет на работу всей системы. Абсолютно распределенная система со 100% отказоустойчивостью.

maytonDima Tпропущено...


Тут писал 17343378

Я не понимаю как тебе поможет UDP? Ты пишешь про GSM и гигабит? Чувак ! жиэсэм работает на килобитах.
На жалких (!) килобитах. Ты даже не почувствуешь улучшений. Только усложнишь протокол контроля
над приёмом.
У этих жалких килобитов большие буферы для кэша, хуже что они тупо рубят UDP, 1-2 пакета из окна проходят. Это 2-3% клиентов, можно на них пока просто забить, потом сделаю TCP туннель до сервера в инете. Тоже писал 17343472

Наверно надо главное рассказать, иначе просто непонятно задлянафига эта хрень. А главное вот в чем: есть приложение (точнее набор приложений) через которое работают мои клиенты со своими котрагентами (тоже мои клиенты), работают ежедневно 24 часа в сутки. Сейчас весь обмен между всеми идет через центральный сервер. Стоит ему упасть - через 5-10 минут все три телефона техподдержки звонят не умолкая, на каждый звонок дается отработанный ответ "попробуйте повторить через 15-20 минут" и ложится трубка чтобы она тут же зазвонила и это сказать следующему. Больше чем на 30-40 минут сервер не падает. Если он не падает, то звонков всего 5-10 в день. У меня техподдержка изучила весь инет и все фильмы посмотрела на работе :)
Но однажды DDoS`ом сервер положили на сутки, точнее меньше, но стандартная реакция провайдеров в подобных случаях "извините, но нам не нужен такой клиент", т.е. идите лесом и не мешайте нам работать. Вот тогда я и пришел к понимаю того что нужна не скорость а надежность. 100% надежность неубиваемая ничем.
Сейчас проблемы частично порешаны дублированием большинства подсистем, но это полумеры.
Рост клиентов и обрастание сервисами требующими трафика тоже привело к тому что сервер в пиковые моменты перегружен. Трафик через него 10 Тб в сутки. А есть потребность еще нагрузку увеличить.
А тут и надежность, и трафик, и масштабируемость неограниченная.

maytonТоесть ты хочешь сказать что пишешь "мега-распределённую" 100% доступную систему
которая каким-то чудесным образом решает проблемы "падающего" центрального сервера?
Да. Только не любого центрального сервера, а моего. По сути это просто хранилище для обмена документами. Всегда доступный файлообменник с логированием обмена и веб-мордой для администрирования доступа.
Если утрированно описать: есть два типа пользователей, пользователь типа А получает некоторую инфу от пользователей типа Б, работает с ней и результат отправляет Б.
Проблемы выхода в инет на стороне А - решает А. На стороне Б - Б. Но А не интересует что у Б проблемы. Пользователь А может захотеть поработать в любой момент, поэтому пользователь Б регулярно освежает свою инфу на сервере.

В идеале А должен обращаться напрямую к Б. Сервер нужен только потому что пользователи Б не всегда доступны.

И инфа разная: одну главное принять и гарантированно доставить, другая становится неактуальна через несколько минут, третья - несколько миллионов файликов из которых раз в год может понадобится 5-10, но очень срочно, четвертая ...

По сути мне нужна система обмена сообщениями произвольного размера. Начал с джабера, там проблема с размерами (100 кб очень много), изучал очереди сообщений (разные *MQ), там тоже не совсем то, а потом появилась мысль чем UDP-пакет не сообщение? :)

Изначально все строилось под диалап, т.е. зацепился-скачал/отправил-отцепился, сегодня все на выделенках сидят. Тут уже морально устарел мой сервер, пора менять архитектуру.

BarloneЯ так понимаю, это продолжение темы http://www.sql.ru/forum/1124178/p2p-po-udp?hl=
Нет. Тут и там разные части одной темы. Тот пока не реализованный. Заготовка для версии 2.0 :)

maytonА работа с документами предполгает только чтение?
Да. Чтение имеющихся и создание новых.

maytonЯ о другом. Могут ли одновременно два пользователя открыть 1 документ и редактировать его?
Нет. После создания и отправки документ никем не правится. По аналогии с платежкой: отправил в банк - править нельзя. Захотел отменить (пока банк не успел деньги списать) - шли документ "отмена платежа" и т.д.