ИзопропилDima T,

а это не у тебя в своё время udp пакет через говнопровайдера не проходил (на торрентовый похожий) ?
Хорошая у тебя память :) У меня, тоже самый говнопровайдер, мой резервный канал, порешал просто, пакеты xor`ятся 4 разными масками, первые два бита задают номер маски для расшифровки. Т.к. рубятся по маске редко, то хватает для прохода фильтра.

Изопропил, я решение там писал с кодом 15819840

maytonДима. Ты действительно думаешь что 2-3% потенциальной скорости - это та вещь за которую нужно бороться.
Нет, я же написал что прощаю TCP эти 2-3%.
maytonрешать различные проблемы канала? И писать кастомный софт? И создавать свой протокол?
Не надо утрировать, я же тебе расписывал суть задачи 17392803 . Соединение А-Б в большинстве случаев по TCP невозможно из-за технических ограничений (на роутерах никто не захочет порты мапить, компам постоянные IP давать, слишком много лишних телодвижений).

Гнать все через сервера не лучший вариант: во первых создаем узкое место в виде серверов-передастов, т.е. в один прекрасный день все начнет тупить и надо будет что-то делать. Во-вторых сервера просто физически далеко (нет у нас датацентров на каждом углу), тоже писал что 100 км по UDP намного быстрее 6000 км по TCP. В третьих это уже есть.

Потом софт все равно писать, какой-то протокол все равно изобретать. Я ж не просто эмулятор TCP пишу.

Да и с TCP не все так гладко. Например в схеме А->Сервер->Б если скорость А->С значительно выше С->Б, то серверу надо где-то хранить то что накачал от А, пока Б это выкачивает. Т.е. опять надо какой-то протокол управления входом от А. Про два сервера еще не задумывался (А->СерверА->СерверБ->Б), тут вообще жесть с кучей неизвестных.

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

Про 2-3% вы не в ту сторону смотрите. Я же писал уже про время отклика, это главное. Представим обычную трехзвенку, клиент обращается к серверу приложения. В локалке - чудесно, надо доп.офисы - поднимаем vpn. Быстро, но дорого, т.к. админа надо. Начальство говорит надо в инете чтобы было, делаем клиента в виде сайта, уже не быстро но все равно дорого.

А тут пофиг где клиент, в локалке или где-то рядом связанный с локалкой одним провайдером или во втором провайдере, которые сязаны внутригородским узлом обмена трафиком. vpn получается на уровне конкретной проги. Свобода полная: хоть из дома работай, хоть в трех офисах как в одной сети. Для организации канала затрат 0, сам организуется. И это реально т.к. внутрисети нормальных провайдеров уже гигабиты, а локалки обычно 100 мбит, т.е. допофис не поймет разницы если будет прямая связь центральным офисом. Просто берем ноут с прогой и едем куда надо, подцепляемся к инету - прога работает. Т.е. совсем другая степень свободы.

Но все упирается в время отклика: незаметное время для человека 1/16 сек. (62,5 мс). Если в это время уложится, то пользователю будет казаться что прога мгновенно реагирует на его действия, не уложится - прога тормозит. Сам понял это когда сидел дома в терминале до офиса через вайфай, вроде 50 мбит в тестах по локалке, 100 мбит до офиса по внутрисети, но пошаговая стратегия какая-то, час поработаешь и бесить начинает, взял перфоратор, просверлил дырку, кинул провод и терминал залетал. Тут цель таже - кто захочет чтоб залетало - просто посоветовать воткнуть провод вместо вайфая. Захочет - воткнет. А если начать гонять трафик через сервера то этот прогон просто сожрет большую часть этих 60 мс и на полезную работу времени не останется. В моем случае это 30-50 мс, скорость света она нифига не быстрая, всего 300 км/мс, а рядом нормальные сервера поднять проблематично. Победить эти 30-50 мс значит сэкономить 50-70% времени на полезную работу.

maytonА ты говоришь - 30-50 мс.
Если смотреть глобальнее, то проблема в финансовых подходах: восновном продают результат, т.е. "систему под ключ", хотите переделать, пожалуйста, вот вам новая "система под ключ". А тут на тебе самоконфигуриющаяся система, продавать нечего, да еще ти за конфигуратором следи, прямой конфликт финансовых интересов. С другой стороны кто первый внедрит - тот победитель. Капитализм, будь он не ладен.
maytonЯ как-то шутки ради прикидывал какой будет лаг с интернетом между Землёй и Марсом.

Ну... вобщем 22 минуты самое короткое время летит радио-сигнал (в наилучшем положении
планет). Вот так вот.
Откроешь офис на марсе - обращайся, что-нибудь придумаем :), у меня юзеры дальше 100 км редко от офиса разъезжаются :)

maytonЯ не очень верю в самоконфигурирующую систему.
Что смущает? Конфигуратор прост: А и Б залогинились, сообщили серверу кто-где, потом просто поддерживай связь с сервером и спрашивай у сервера где тот кто тебе нужен. Чтоб сервер не был узким местом - подними несколько и репликацию состояния между ними. 100% надежность задешево .

maytonОсобенно в условиях когда между А и B трейсроут показывает OVER 9000 устройств каждое из которых со своей характеристикой.
Тут уже заточка на уровне прикладного софта. Есть быстрый отклик - переключайся в режим толстого клиента, нет - работай тонким (кэшируйся по максимуму), работать будет, но с затуплениями. Не нравится - выкинь GSM-свисток и воткни провод.

maytonЕсли-бы у тебя была задача - проектировать сеть под конкретную специфику ПО. В условиях
когда ты сам выбираешь оборудование, и софт. Тогда можно было-бы что-то придумать. Заточить
под длины сообщений.
Я ж не центробанк и не ФАПСИ, это они себе могут позволить собственные большие сети. Мне скромнее надо быть, у меня только софт свой, интернет наше всё :)

maytonНадеюсь тебе заплатят за доработку.
В этом плане все отлично. Платежеспособная потребность есть.

maytonДима. Ты действительно думаешь что 2-3% потенциальной скорости - это та вещь за которую нужно
бороться. И решать различные проблемы канала? И писать кастомный софт? И создавать свой протокол?
mayton, ты неправ!

Поизучал немного TCP (опыт реального использования меньше двух недель см. выше когда начал). Эйфория от его простоты и быстрости улетучилась. Ничего там не просто если хочешь асинхронно с ним работать, надо городить свой протокол поверх. UDPшная надстройка подошла для ускорения TCP (с небольшими поправками), но на медленных каналах только усложняет все. В принципе есть мысли как сгладить проблемные места, но не нравятся они мне, полумеры какие-то.

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

По поводу скоростей TCP и UDP: до хостингов это не 2-3%, а до 2-3 раз. Один из случаев шлю 3 мб туда-обратно (раз 20 запускал): UDP стабильно дает под 60 мбит (пару раз 40-50), TCP туда от 20 до 40 (один раз под 60), обратно 40-60. Как они строют распределение пропускной способности не знаю, но вижу что строют и затачивают на исходящий трафик, а UDP эту заточку просто не попадает, хотя тоже не факт что при большом UDP-трафике не начнут против него затачиваться. Это хороший хостинг (он падает меньше всех из мною используемых), на плохом все отлично 100 мбит в обе стороны по обоим протоколам (может больше, я по 100 мбит подключен), но этот хостинг может запросто упасть на пару дней (было), как понимаю просто криворукие админы не умеют сбаллансировать нагрузку и при ддосе все просто умирает, т.е. сделал вывод там где умные админы скоростей ожидать не стоит, а там где тупые - надежности.

maytonСкорее всего ты наткнулся на TCP-shaper. Для UDP его просто не настраивали.
Я в нескольких местах на него наткнулся. Описал один из случаев. То что он появится для UDP не сомневаюсь, если ощутимый трафик будет. Но сомнительно что он появится в оконечных подключениях, т.е. те самые А-Б которые не могут себе TCP позволить. Они будут ограничены только скоростью своего безлимитного тарифа. Как показали мои испытания на моем говнопровайдере - заявленные 40 мбит я получаю по UDP стабильно, а по TCP через него не видел больше 30-32, т.е. как-то он зажимает TCP. Второй провайдер почти одинаково пропускает.

Тема не стухла. Я ее думаю вместе с акторами. Но как-то рука не поднимается взять и написать. Наверно пора.

maytonНа днях подключу свой Raspberry-Pi к ноутбуку. Полезность эксперимента в том что подключу к ноуту
перевернутым патч-кордом и можно померять скорость на максимуме.
Тухлый эксперимент, не могут они гигабит выжать, процы слабые. Мерил на кубике (cubie), из 100 мбит с трудом 50 выдает.

maytonНу и wifi. Давно хочу добраться до него. Разгромить этот маркетинговый шлак.
На коробке написано - 300Мбит. Посмотрим какие там триста. Еще интересно
когда роутер держит 2 соединения. Как он там? По частотам? По частоте + ВРК?
Это как с дисками. Может и есть 300 потоком в одну сторону, а туда-сюда - тормоза. Я уже писал что в терминале работаю, дома вайфай в нем впн до работы и терминал, по вайфаю было как в пошаговой стратегии, прокинул провод от роутера до компа - стало все хорошо.