Dimitry SibiryakovDima Tкак обойти NAT я выше написал.
Хрен ты провайдерский NAT обойдёшь. Он работает в паре с файерволлом (на котором,
собственно, и построен).

Что ж за упорство такое мое начинание обгадить. Зачем провайдеру умышленно гадить своему клиенту? Как будто я вирусню какую рассылаю или спам. Не вижу ничего криминального.

Пофиг так-то, там где технические меры не помогут - задействую экономические. Объясню клиенту что провайдер у него ниочем и приведу в пример другого клиента с другим провайдером. Владельцы бизнеса хорошо понимают когда им говоришь что ты тут экономишь пару сотен рублей на интернете, а теряешь тысячи, особенно если привести в пример конкурента у которого сервис работает по-максимуму. Хотя есть трудные: один принципиально сидит на диалапе только чтоб никто в рабочее время в соцсети не лазил.

В общем тесты на клиентах покажут на что рассчитывать, хотя теория и тесты уже вдохновляют. Планирую эту разработку для запуска доп.сервисов связанных с возможностью обмениваться инфой в реал-тайм между клиентами, а не запрос-ответ по инициативе пользователя как это обстоит сейчас.

Лично мое мнение за p2p и UDP будущее. Сейчас активно развиваются сервисы по передаче видео, а это гигантский поток. Взять тот же SmartTV, который по сути интернет в телевизоре. Слать каждому зрителю то что он хочет смотреть нереально, посчитаем: среднепожатый HD фильм 4-5 Гб на 100 минут видео, т.е. 4000 / 100 / 60 * 8 ~ 5,5 мбит потока полезной инфы плюс заголовки пакетов будет все 6 мбит/сек и это на 1 (одного) пользователя, а для нормального бизнеса надо миллион пользователей, т.е. 6 террабит/сек., да ни один канал такого потока не выдержит. А тут есть p2p (которое вроде как и пользуют) позволяющее размазать трафик по клиентам, т.к. они смотрят не миллион разных фильмов, а гораздо меньше, но разные места фильма.

Basil A. SidorovDima TЧто ж за упорство такое мое начинание обгадитьЧто за упорство такое смотреть на мир через розовые очки?
Причем тут очки? Конкретных фактов не приведено, есть просто общий скепсис опытных разработчиков по отношению к моей задумке. Это нормально, я так же отношусь к чужим "гениальным" идеям. Я не ожидаю встречного восторга от моего велосипеда с квадратными колесами. Но квадратные колеса имеют свои плюсы при езде по пилообразной дороге :)

Basil A. SidorovЗачем провайдеру умышленно гадить своему клиенту?"Ничего криминального - только бизнес".
Некто собрался зарабатывать на мне деньги. Мои деньги. Не вопрос, но не надо ждать, что такому ушлому бизнесмену будет открыть зелёный свет.
Теории заговоров оффтоп для данного форума. Не хочу спорить какова доля правды в данном утверждении.

Basil A. SidorovВ общем тесты на клиентах покажут на что рассчитывать, хотя теория и тесты уже вдохновляютС "хорошей" теорией и "правильными" тестами - всегда так.
Пока проведены предварительные тесты, которые говорят что надо писать. Пишу. Как допишу проведу тесты на всех своих клиентах. Тогда и сделаю окончательные выводы о пригодности моей задумки.

Остальное не буду комментировать.

PS Допишу - выложу на всеобщее порицание.

ИзопропилDima TЭто п.1, а как обойти NAT я выше написал.
почитал бы про типы NAT сначала(rfc 4787)
Ниасилю, там много непонятных английских букв :)
Да и дело не в натах, а в ограничении и фильтрации трафика провайдерами, вирусную активность пресекают и слишком любящих покачать все на свете домашних пользователей ловят. Думаю про это rfc не пишут.
Я уже попался :) пытался без сервера своих UDP-клиентов соединить из-за виндовых брандмауэров, написал сканер портов встречный, т.е. указываешь проге IP и он его ему шлет маленький пакетик на все порты, а на том IP такая же прога навстречу. Пролетело - соединились. В локалке заработало, направил на внешние IP натов ... инет отпал через минуту )))

И не критично это. Ну не заработает между двумя клиентами p2p - есть сервер, через него трафик пропущу. Просто реально может оказаться что оба клиента на одном провайдере, в одном городе, а трафик пойдет на сервер и обратно 5-7 тыс.км. Так и ходит сейчас. Не быстро получается. Также при наличии p2p можно было бы пользователям предложить удобный канал обмена их собственной инфой между их точками. Отсутствие узкого места в виде сервера значительно расширяет потенциальные возможности.

ИзопропилUDP пакеты в 6000 байт - это сильно, при передаче они разбиваются на фрагменты, один фрагмент выпал - и пропал весь пакет.да и нет никаких гарантий, что длинный пакет пройдёт по сети(rfc 5405)
Ну это я опытным путем выяснял какие пролазят. Лучше бы по-простому сказал какой максимальный размер взять.
По результатам тестов пришел к размеру 1372 байта. Пока остановился на нем. Это предел для L2TP подключения с MTU 1400.
Поиски по инету ответа не дают. Есть магическое число 1280 от MS в описании настройки DNS
Есть RFC 1191, где упоминается магическое число 576, правда сам RFC 1990 года рождения.
rfc 5405 попробую осилить. Там тоже 576 упоминается для IPv4

Уменьшить макс.размер можно и до 512, только смущает доля служебной инфы 6,5% против 2,5% для 1372. (20 байт IP заголовок + 8 UDP + 10 мой). С другой стороны разбиение на фрагменты похоронит всю экономию и даст доп.тормоза.

Как раз добрался до тестов максимально возможной скорости. Идея такая: слать окнами по десять пакетов и выравнивать интервал по времени, т.е. например засечь время, послать 10 пакетов макс.размера, дождаться окончания 1 мс, следующие 10 пакетов и т.д. И найти такой минимальный временной интервал при котором без потерь будет идти непрерывная передача. Тут заодно можно будет посмотреть как размер пакета влияет на общую полезную скорость и потери.

miksoftDima Tпослать 10 пакетов макс.размера, дождаться окончания 1 мс, следующие 10 пакетов и т.д.Может, у меня с арифметикой что не так, но по моим подсчетам это поток порядка 100 Мбит/с.
Такого интернета у большинства и близко нет. А у некоторых до сих пор 32 Кбит/с.

Оффтоп: Кстати, практически единственный современный сайт, который юзабелен при 32 Кбит/с - это sql.ru :)
1 мс это для примера было, пусть 1 сек. Хотя на 100 Мбит и придется тренироваться в локалке. Хочу разработать методику определения скорости 5-10 пакетами, в идеале с полезной инфой. Хотя максимальная заточка должна быть на те случаи когда все плохо, в первую очередь GSM модемы с неуверенным приемом. Из них надо выжать максимум, а если из доступных 100 Мбит получится 10 - неважно.
Basil A. SidorovНе изобретайте вы TCP на коленке ...
Про стандартную реализацию производители сетевого оборудования наслышаны и приняли немало усилий для "углУбить и расширить", а вот ваши извращения могут и (невинно) пострадать.
Буду изобретать, т.к. :
1. TCP уже есть в виде HTTP поверх него. По сути файлообменник с распределением доступа по логину/паролю.
2. Нужен онлайн обмен маленькими сообщениями, для расширения функционала п.1

п.2 вписывается в особенности UDP идеально, т.к. не заработало по-новому - никто и не заметил, т.к. дальше работает по-старому не догадываясь что может быть лучше.

написал много букав про то чем плох п.1 но стер, т.к. это наше грязное белье не для всеобщего обсуждения
Сухой остаток в том что в идеале я вообще хочу избавится от п.1, мне не нужен сервер, это единственное слабое место в моей системе. Все остальное децентрализовано. Какой бы не был хороший провайдер у которого сервер (а провайдер реально молодец, есть с чем сравнить) он не даст гарантию 100% бесперебойной работы, а 99,99% меня не устраивает, довел до 99,999% использованием второго сервера выполняющего критические ко времени функции первого в случае его отказа, но это полумеры. С UDP я уже спроектировал много-серверную систему с резервированием передаваемых данных, 100% устойчивую к падению одного сервера в час. В случае если p2p заработает, то отказоустойчивость будет 100500%, т.к. каждый клиент станет нужным ему же сервером.

miksoftDima TХочу разработать методику определения скорости 5-10 пакетами, в идеале с полезной инфой.Может, не стоит морочиться с замером скорости, а просто ожидать квитирования после каждых 1-10 пакетов?
Стратегически неправильный подход. Должен быть запас прочности. И чем больше - тем лучше. Можно изначально написать лишь бы работало, а потом ломать голову как улучшить когда будет работать плохо.

Да и просто интересно. Чисто спортивный интерес. Понять как могло бы быть идеально и как далеко от идеала то что получилось. То что будет в итоге не идеально я не сомневаюсь, просто хочу знать насколько.
miksoftUDP, кстати, еще хуже тем, что некоторые операторы UDP-пакетам на нестандартных портах дают меньший приоритет, чем для TCP. Если у какого-нибудь такого маршрутизатора по дороге интерфейс "в полке" (т.е. длительно загружен на 100%), то он дропнет все ваши пакеты, а не только 90%.
Отказаться от UDP никогда не поздно, это просто усложнит решение, я изначально изучал различные системы обмена сообщениями (*MQ) на основе TCP и в итоге пришел к выводу что они своей сложностью только усложняют решение моей задачи, но не дают идеального решения, что-то конечно дают, но не все что надо и очень дорого в плане сопровождения. В итоге пришел к выводу раз изначально все ненадежно, то пусть будет совсем ненадежно, но просто.

Работая на низком ненадежном уровне можно элементарно передать данные со 100% надежностью: Клиент А хочет что-то передать Клиенту Б. Передает всеми доступными способами (напрямую, через доступные сервера, голубями и т.д. чем больше способов доступно тем лучше) пока Клиент Б не скажет я все получил, затем назначается координатор транзакции, который относительно надежный но на всякий случай дублирует себя вторым относительно надежным. Суммарная надежность координаторов 100% если они не умрут одновременно, выживший продублируется третьим и т.д. В итоге Клиент А на 100% уверен что Клиент Б всё получил. Как-то так :)

Разобрался с потерями в 90%. Все до безобразия просто: виндовс не может отправить два пакета подряд (независимо от размера). Даже с 127.0.0.1 на 127.0.0.1.
такой код почти никогда не отправит второй пакет


но стоит поставить


и все уходит. Только я так подозреваю что тут дело не в 1 микросекунде, а в том что именно в момент такого вызова ОС начинает отправлять, а потом выходит из select() по таймауту.
Нездоровая фигня, но в целом меня это устраивает.

Причем размер пакета тут тоже никак не влияет хоть 10 байт хоть 1024. Тест из 10000 пакетов через 127.0.0.1 уходит 10 сек и на пакете 10 байт и на 1024.

Я все это заметил только когда отладочные printf() убрал. Наверно пока они печатались ОС иногда успевала sendto() обработать и второй срабатывал нормально. И было вообще непонятно в чем причина и как ловить.

PS Сделал p2p клиента с узнаванием друг-друга через сервер. Причесываю исходники. Выложу чуть позже.

ИзопропилDima T

здесь - ошибка. перед копипастом полезно документацию читать
Ты сам читал?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx int select(
_In_ int nfds,
...
Parameters
nfds [in]
Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
...
Это как раз правильно, MS пофиг, а линукс только так и понимает.

PS копипаст из моего же творчества.

Dima TРазобрался с потерями в 90%. Все до безобразия просто: виндовс не может отправить два пакета подряд (независимо от размера). Даже с 127.0.0.1 на 127.0.0.1.....
Неправильно написал, это убирает потери на стороне отправителя, т.е. с такой паузой виндовс отправит много пакетов. Потери в каналах доставки остаются, но там они боле-мене понятны: шлешь много пакетов с большой частотой - много теряется, шлешь с маленькой частотой - все доходят. Дальше надо решать задачу поиска середины.
Непонятки были из-за отправки: хоть на 127.0.0.1, хоть по гигабитной локалке - все равно потери, причем разные т.к. из-за отладочных printf`ов отправитель подтормажимал и в эти моменты виндовс успевал что-то отправлять.

Anatoly Moskovsky(просто идея)
А попробуйте вместо задержки вызывать flush для сокета после отправки.
flush() - не нашел такой функции, может речь про файловый fflush() - не компилируется " cannot convert parameter 1 from 'SOCKET' to 'FILE *'"
если насильно fflush((FILE *) sock) - вылетает.

Dimitry SibiryakovЛучше будет всё-таки не отправлять сообщение в сокет, которому select вернул состояние
"можно читать".
Выше пример упрощенный, чтоб не грузить лишними деталями, полные исходники тут (см. udp_dialog.h) , если селект вернул "можно читать" происходит чтение. Проблема была именно когда читать нечего и надо дважды отправить.
Dimitry SibiryakovА ещё лучше - не выпендриваться с неблокирующими сокетами вообще.

Большим спецом по сокетам себя не считаю, могу заблуждаться, но сокет блокирующий. На recvfrom() он останавлиивается, пока что-нибудь не примет. Для того и select() чтоб все не встало в ожидании приема.