miksoftDima TЕсли Б заддосят - это его проблемыТехнически - да, его. А репутационно?
Попробуй докажи. Может просто меня выбрали как способ вычислить где он.

miksoftDima Tнет ярковыраженных ключевых клиентовПри слабых абонентских каналах не проблема заддосить сразу несколько сотен/тысяч ваших клиентов тупым флудом. Главное - узнать их более-менее свежие адреса. И уже неважно, что половина атак уйдет мимо.

Надеюсь, конечно, что такого никогда не случится, но мало ли?
Тут узнать проблематично. Софт закрытый. Авторизация. Клиент всех других клиентов не знает, спрашивает сервер. Нет такого состояния "попинговать всех". Тут разве что слушать куда идут пакеты. Поэтому максимум десяток-другой потенциальных жертв с кем общается прослушиваемый. Накопится десяток - по логам можно будет вычислить наводчика.

miksoftDima TТут узнать проблематично. Софт закрытый.Элементарно. tcpdump/wireshark никто не отменял.
я про это написал "разве что слушать куда идут пакеты". отконкретной ноды идут они далеко не всем.

Вообще проблема ддоса из серии как уговорить гопника: "он тебе бъет в лицо, а ты его убеждаешь словами что он не прав". Так нерешаемо. Тут надо переходить на тот же уровень общения.

miksoftDima TКто предъявляет за оставшийся 1%Похоже на мой случай
Да, есть такое что оставшийся 1% требует столько же трудозатрат (если не больше) как предыдущие 99.

maytonДа он хакерам нужен как и Лимонадный Джо... Вот в таком аспекте.
В анекдоте было не лимонадный, а неуловимый, типа "нафиг никому не нужен, потому неуловимый" :)

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

Про ддос: Ддос штука недорогая, цены в инете, но нет смысла на ддосе заостряться, в любой защите всегда бьют в самое слабое место. Ну сделаю я супер защиту от ддоса, перейду дорогу кому-то сильно большому по бизнесу, пришлют гопников, сломают мне шею, или ментов, которые меня в СИЗО посадят, тоже недорого организовать. Зачем заморачиваться на изощренный ддос? Я к тому что в гадостях не надо мыслить только ИТ-категориями.
Суть не в этом, эта тема вообще неинтересна, она была интересна когда попал первый раз, сейчас выработано 100500 стратегий обороны.

Как уже выше написал ищу 100% отказоустойчивость для работы конкретного оконечного узла, он не должен видеть что где-то что-то не работает, если у него все нормально, то для него вся система должна выглядеть абсолютно работоспособной.

maytonДа пофиг. Лимонадный гуглится тоже.
Вобще пофиг, оба не в тему )

Безнаказанное нарушение ACID гораздо интереснее.

maytonНовости Хабр просматриваю. Каждый второй топик тебе в пыщь.

http://habrahabr.ru/post/249563/

Везунчик...
Спасибо, почитаю. Я хабр регулярно почитывал, пока эту чудохрень усиленно дописывать не начал в свободное время. Затягивает :)

Почитал, половину не понял. ИМХУ борьба с последствиями. Надо причину убирать, т.е. децентрализовывать. Чудохрень рулит :)

Добавил TCP-туннель, для UDP. С дефолтными параметрами TCP не взлетело в гигабите, чуть выше 100 мбит. Поставил сокетам буфера приема/отправки 0,5 Мб, стало веселее. Тестил между двумя компами воткнутых в один гигабитный роутер. Гонял 100 Мб в обе стороны. Т.к. под TCP не заточено, просто туннель для UDP, то немного пошаманил с настройками, для UDP окно 32 пакета, в TCP 128 (потом допилю чтобы в TCP пихалось пока не перестанет влазить).
Статистика (туда/обратно мбайт/сек):
мой UDP: 85/90 мб/с
ТСP 65/80 мб/с
Грустно. Оказывается заголовок TCP больше (40 байт против 28 у UDP), а я шлю максимальными UDP пакетами (1472 байта данных при MTU Ethernet`а 1500), урезал порцию до 1460. Стало 89/92 мб/с, тут TCP уже победил :(

Ради спортивного интереса запусил UDP c окном 128 и буферами 15 мб - результат 91/95 мб/с. Пытался выдавить из TCP столько же, не смог. Тестил FAR`ом, копирует гигабайтные файлы 88-89 мб/с.

Вывод: в локалке UDP быстрее. По инету пока не готов сказать, недописано. Как будут результаты - отпишусь.

Что-то не взлетает у меня TCP в инете. Тестю до виртуалок разной удаленности. UDP быстрее, местами в разы. Есть мысль что рубят скорость TCP злобные провайдеры, но пока ее отодвигаю, исхожу из того что сам что-то не доделал.
Может кто подскажет что подкрутить. Пока немного помогло увеличение буферов до 0,5 Мб, пробовал 5 Мб ничего не меняется, значит что-то еще мешает.
Я об этом


Что еще подкрутить?

maytonЕсть мысль что рубят скорость TCP злобные провайдеры
Сколько ты хочешь "выжать" из Инета?
Больше чем выжимаю по UDP между теми же пирами. Я почти проникся тем что TCP быстрее, теоретические основания этому есть (заточка оборудования под TCP и т.п.), хочется подтвердить на практике. Результатами замеров пока не хочу делится (как минимум надо перемерить на свежую голову), сначала сам переварю, пока предполагаю что у меня что-то не так, все-таки UDP долго затачивал, а тут пока просто не взлетело.

Главный вопрос стоит так: как сильно использовать TCP. Минимально туннель до сервера (чтобы с него GSM-свистки гарантированно принимали/получали), максимально заменить UDP там где это даст ускорение. Истина где-то посередине. Пока в поисках оптимальной стратегии.

maytonDima T, мне кажется странным что основная твоя конфигурация - это машина на базе Windows.

Не пробовал рассмотреть варианты CentOS, FreeBSD ? Там сетевые возможности более "взрослые".
Идеальная платформа для экспериментов.
Это был первый этап, локалка, она обычно win-win. Какой смысл уходить от реальности? В инете виртуалки debian7x64, разной удаленности (ping от <1 мс до 50 мс), на них мои сервера. Сейчас второй этап - ускорение связи с виртуалками, т.е. win-linux. linux-linux пока не проверяю, в моем случае это сервер-сервер, по проекту тут нагрузка должна быть незначительна, основная клиент-клиент, т.е. win-win.

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

По простому: хочется сделать хорошо и забыть на 10 лет (как в прошлый раз).

maytonКакого класса система тебе нужна?
Система передачи данных (сообщений с данными), т.е. доставка должна произойти обязательно и желательно максимально быстро.
Все ситуации сводятся к обмену между двумя клиентами (А и Б). Каждый может быть как прогой с тыкающим в нее клавой и мышей юзером, так и роботом висящим где-то в фоне на каком-нибудь сервере.
Два вида обмена:
1. Двунаправленный: А отправляет запрос инфы, Б в ответ присылает инфу. Запрос маленький (до килобайта) ответ побольше (10-100 кб). Тут скорость важна, т.к. А ждет ответа.
2. Однонаправленный: А отправляет инфу Б. Размер инфы 1 Мб. Скорость не критична, но чем быстрей тем лучше.

Далее имеем варианты доставки:
1. Через сервера (А и Б не знают где кто, для этого каждый регается на одном из серверов), т.е. худший случай А -> СерверА -> СерверБ -> Б
2. Напрямую (если знают)

Изначально первая доставка начинается с варианта 1 и в процессе (по возможности) перестраивается на вариант 2.
Т.е. в целом так для двунаправленного обмена: А отправляет по в.1 запрос, запрос влазит в первый пакет, который по приходу запускает подготовку ответа на Б, в это время транспорт перестраивается на в.2 и ответ идет по наикратчайшему пути.

Чем конкретно будут обмениваться? Да хоть чем, хочется максимальной универсальности. Из идей что можно дополнительно прикрутить сверху: резервные копии гигабайтных бэкапов, просмотр окна проги позвонившего юзера (мини VNC) и т.д. и т.п. Может мои клиенты (человеки) под свои нужды захотят как-то мой транспорт использовать.
maytonЧто ты исследуешь? Скорость Интернета? Это - метафора. Нету интернета.
есть конкретная скорость конкретного канала.
Скорость конкретного канала между случайными А и Б. Точнее я исследую как из канала выжать максимум, т.е. как максимально эффективно подстроится под каждый вид канала.

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

Вобщем исследую плюсы и минусы всех составляющих и их комбинаций, чтобы понять как использовать. Можно P2P по TCP сделать (например есть робот к которому часто обращаются, замапить порты на роутере, обращающийся будет знать и цепляться). Вопрос надо ли это? Будет ли польза? Опыты в локалке уже показали что в локалке пользы не будет, т.к. UDP не теряется.

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

Наблюдения:
1. Размер данных: стоит только начать давать на байт больше чем MTU, так сразу фрагментация замедляет передачу. Особенно заметно на быстром канале. 100 мбит падает до 50-60 если давать блок данных чуть больше. Например если MTU 1500, даешь 1461 байт данных + 40 заголовки TCP и IP т.е. пакет 1501 - тормозит, опускаешь данные до 1460 скорость TCP поднимается с 60 до 100 мбит. Причем данная корявость только в виндовсе, из линукса скорость не падает.
2. Виндовс делает маленькие буфера приема/отправки. Например если с буфером по дефолту скорость 2 мбайта/с, задаешь буфер побольше растет до 2,9-3. Линуксу повышение бесполезно.

Вобщем пока все наблюдения говорят о корявости виндовса в работе с TCP.

По поводу тестов скорости UDP vs TCP, то UDP чуть быстрее (2-3%) пока нет потерь, соответственно если потерь больше 2-3%, то TCP быстрее. Считаю эти 2-3% выигрыш за счет простоты протокола. Правда есть неадекватные оконечные провайдеры (у меня такой на резервном канале), там TCP медленнее на 15-20% (2,0 против 1,6-1,7 мбайт/с, тариф 40 мбит). То ли TCP душат, то ли анализировать пытаются, то ли UDP рубить не умеют, то ли еще чего. Тестил через два канала до далекого сервера: пинг 30 мс, 1500 км по карте (если не врут с раположением датацентра).

В итоге все упорядочилось, статистика стала объяснимой.

maytonDima T, в процессе настройки канала между А и Б какие у нас есть факторы?
Из уравнения с многими неизвестными многие неизвестные выпали. См. предыдущий пост.

Сделаю TCP от каждого клиента к серверу и между серверами.

Скорости прохождения пакета:
А->Б меньше 1 мс
А->Сервера->Б 30-50 мс

Если А-Б могут установить TCP-соединение - устанавливать.

Если не могут, то тут нерешенные задачи:
1. в какой момент прекратить А->Б и переключится на А->Сервера->Б
2. Кто из двоих проблемен? как определить кому в будущем приорететнее общаться через сервера?
Известны потери в процессе передачи А->Б, можно замерить TCP скорость А->Сервер и Б->Сервер