miksoftDima TПо сути мне нужна система обмена сообщениями произвольного размера.По описанию сильно на E-mail похоже.
E-mail не решает проблему быстрой проверки доступности получателя. Это ключевой момент. Например А требуется инфа от Б (его текущее состояние), А может получить самую свежую версию прямо от Б, а может из общедоступного кэша не очень свежую, но свежее чем есть у А. Можно конечно и почтой реализовать, но как-то коряво получится.

miksoftНу если только по причине двух встречных NAT-ов (т.к. обычный E-mail работает по TCP). В остальных случаях - не вижу, почему нет.
И НАТов тоже, но не только, тот же пример, рабочее состояние: А отправил, ждет ответа, непрерывно долбит свой почтовик "Есть чего? Есть чего? Есть чего? ...". Б непрерывно долбит свой. Зачем?
Я бы сравнивал не с почтой, а с аськой, интернет мессенджеры ближе по функционалу. По сути задача А максимально быстро получить ответ, т.е. алгоритм: спросить у Б, недоступен - спросить у С.

Хотя может я не понимаю глубину твоей мысли. Намекни попрозрачней :)

maytonВ твоей системе допускается "дубль" документа? Ну тоесть док который создан 1 раз но дошёл дважды?
Есть такая болячка. Решается контролем дублей на принимающей стороне.

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

В итоге решил что транспорт должен быть надежен на 99,9%. Отправитель передав транспорту считает что ушло. Если транспорт не получил подтверждение доставки - сообщает отправителю, отправитель решает как быть дальше. Вобщем контроль на более высоком уровне. Там виднее что делать в каждом конкретном случае.

Для гарантированной доставки транзакция на верхнем уровне (не делал еще): А готовит сообщение, отправляет Б (или в кэш С если до Б не дошло), сообщение получает статус "отправлено" (изменения запрещены), Б по приему сообщает что обработано, если Б долго не подтверждает А шлет запрос проверки получения.

maytonDima T, мне кажется ты пытаешся строить свою p2p сетку. Ну... или развитие этой идеи
приведёт тебя к p2p протоколам. Без центрального сервера.
Уже отказался от этой идеи. Надо как минимум авторизоваться чтобы в сетку войти, поэтому надо несколько серверов для авторизации, а раз они есть, то пусть они и занимаются сведением клиентов и отслеживанием кто в сети. Так эффективнее и безопаснее.

maytonНо я-бы искал решение просто в использовании TCP и нескольких резервных серверов в облаке.
Облако - дурацкое слово от маркетологов. В реале это просто возможности виртуализации в датацентре провайдера, т.е. добавить памяти, места на диске, мощности проца, переселить работающую виртуалку на другую железку. Только сейчас DDoS`ом ложат не клиента, а сразу датацентр. В такие моменты улетучится твое облако и сиди кури пока вернется.

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

Про TCP: можно безболезненно заменить общение клиентов с серверами с UDP на TCP, архитектуру это никак не меняет, клиент уже поддерживает постоянную связь с одним из серверов и гонит через него трафик если не получается напрямую. Т.е. отказавшись от UDP я просто теряю функционал прямой связи двух клиентов. Зачем отказываться? Что быстрее: 6000 км по TCP или 100 км по UDP ?

maytonИ еще почитай про SCTP. Возможно натолкнёт на мысли.
https://ru.wikipedia.org/wiki/SCTP
Почитаю.

maytonЕще до кучи. Теорема CAP. Не знаю будет-ли полезна. Но если да - то неплохо.

https://ru.wikipedia.org/wiki/Теорема_CAP
Банальные очевидные фразы, сам до этого дошел. Не знал что этому название есть.

Хотя он дальше ушел, наверно поэтому я не профессор :), я изначально расщепление исключил.

По теме: после патча сокета во внутрисети провайдера (100 мбитной) скорость с 10`000 кбайт/с поднялась до 11`000+ кбайт/с. Сделал вывод что служебный трафик при грубых расчетах надо выкидывать делением на 9, а не на 10.

maytonЕще до кучи. Теорема CAP. Не знаю будет-ли полезна. Но если да - то неплохо.

https://ru.wikipedia.org/wiki/Теорема_CAP
Спасибо за ссылку. Cильно задумался. Нужно выходить за рамки псевдоаксиом вдолблеых общепринятым образованием.

Почитал хабр. Не сказать что прям такое супер что-то, но на мысли натолкнули. Транзакции с кэшем очень даже можно замутить. Например есть N синхронизированных узлов с одними и теми же данными, проводим транзакцию с одним, он прежде чем подтвердить дублируется на большей половине (т.е. для 5 узлов достаточно дополнительно на 2-х), на остальных распространяем после подтверждения. Это то что сходу в голову пришло. Хороша пища для размышлений. Может правда ну его нафиг этот ACID и центральную БД. Буду думать. Может в версии 2.0 чего-то такое внедрю.

miksoftDima TВ идеале А должен обращаться напрямую к Б.Подумалось... А это нормально, что вы фактически хотите сообщать ip-адреса одних клиентов другим клиентам?
Если попадется один или несколько неблагонадежных клиентов, то очередной DDOS может быть обращен уже на кого-то из добросовестных клиентов, что (помимо, собственно, потери этого клиента) может негативно повлиять на репутацию всей системы.
Или я это уже загоняюсь?
я писал так 17350418
В идеале А должен обращаться напрямую к Б. Сервер нужен только потому что пользователи Б не всегда доступны.
Если Б заддосят - это его проблемы, для того нужен мой сервер с кэшем. С кэша можно забирать почти анонимно, адрес будет видеть только кэш. Воткнул gsm-свисток и качай. Уронить GSM шлюз надо постараться :) Я конечно помогу проблему порешать, но гораздо вероятнее что у Б вырубят электричество или копая теплотрассу выкопают его оптоволокно.
Можно тупо ограничить выход udp в инет только моими серверами. Тогда общение со всеми через них. Т.к. это оконечное подключение - дополнительно попросил другой IP у провайдера и забыл про ддос. Решаемо.

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

maytonDima TМожет правда ну его нафиг этот ACID и центральную БД. Буду думать. Может в версии 2.0 чего-то такое внедрю.
Собственно... всё завит от идеи которая заложена и задачи. Если взять наш мир. Так он нихрена
не централизован и несогласован. И разделен.
+1
Нафиг не надо централизовываться там где не надо. в большинстве случаев: если задача решена на 90-95% этого достаточно. Если при этом оставшиеся 5-10% не выкинуты за борт, просто по ним предложено более убогое решение.
В реальном мире есть понятие КПД, никто не стремится сделать его 100%, точнее стремятся, но спокойно живут с тем какой есть. Лично я давно уже придерживаюсь такой практики: решено на 90% - нормально, на 99% - идеально. Кто предъявляет за оставшийся 1% - в итоге сами соглашаются что это придирки. Закон Парето никто не отменял.