Архитектура распределённого месенджера, request for comments?

Question

[bak]

Привет. Опишите пожалуйста, на ваш взгляд, слабые места такой архитектуры.

Пока что я вижу следующие:

— не является честным p2p, есть централизованные элементы

— безопасна к перехвату, но не рассчитана на анонимность

— является очередным велосипедом

По первому минусу — он позволяет значительно упростить реализацию и интерфейс, оставляя его таким же, как и большинства популярных IM. Децентрализация достигается за счёт неограниченного количества серверов.

По второму — любые штуки, гарантирующие анонимность будут усложнять архитектуру, уменьшать скорость работы и увеличивать трафик. Кроме того частичная анонимность всё же будет доступна — при отправке сообщений через сервер прямой ip сходу определить не получится.

По третьему — наиболее близкая архитектура у XMPP. Основные отличия:

— шифрование сообщений, сервер не может дешифровать сообщения пользователя (в XMPP — по умолчанию — можно).

— прямые соеднения между клиентами (&обход NAT)

— google protobuff (вместо XML)

— встроенные в основной протокол аудио & видео звонки.

— отсутствие в протоколе расширений и запрет на модификацию протокола (нельзя сделать клиент, который, к примеру, использует другой видеокодек).

Хотелось бы услышать конструктивную критику.

Answer 1

[ntkt]

Я бы пошел дальше и попытался бы разработать не просто распределенный мессенджер, а полностью распределенный и децентрализованный транспорт+key/value storage, удовлетворяющий заданным требованиям (надежная взаимная аутентификация + анонимность + non-repudiation +… ). Задача, конечно, довольно амбициозная, но почему бы и нет?

Comments

[bak]

Хорошая идея, но это более сложная задача. И сложности начинаются когда хочется сделать чтобы эта сеть была устойчива к атакам. Поэтому я решил для начала несколько упростить и сузить себе задачу — как правило попытки сделать универсальную мегаштуку заканчиваются не очень удачно :) консистентный отказоустойчивый распределённый kv storage сложно сделать даже в пределах нескольких ДЦ с надёжным каналом, а если в качестве нод выступают обычные пользователи всё становится гораздо интереснее :)

[ntkt]

Мне кажется, интересно было бы подумать над концепцией такой даже не мегаштуки, а меташтуки.
Попробовать наваять высокоуровневую модель вообще без привязки к реализации, алгоритмам, протоколам.
Если в построенной по исходной модели гипотетической системе будут выполняться заданные отношения и условия, то поверх нее можно будет развернуть что угодно (на это указывают попытки нецелевого использования существующих технологий — хранение данных в блокчейне bitcoin, передача данных поверх DNS, IM на базе DHT и bittorrent и т.д.).

[rPman]

Настоятельно рекомендую bak не слушать такие 'рекомендации', не нужно охватывать необъятное! Анонимностью пусть занимаются соответствующие для этого инструменты, не думаю что будет большой проблемой добавить поддержку i2p в клиенты и серверы (в крайнем случае поддержка socks прокси и использование доменов .i2p все решит автоматически).

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

---

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

Но из особых пожеланий — реализуйте для управления контактами поддержку меток (тегов), это наиболее гибкий и универсальный метод.
Если брать аналогию, можно смотреть на категории в скайпе, но там допущена фатальная ошибка, эти категории никак не отображаются у самих контактов (а нужно), а так же нет возможности отображать контакты на базе этих категорий отлично от 'контакты категории X' (а нужно к примеру 'контакты категорий X и Y' или даже 'X или Y или Z', т.е. более гибко, поэтому я и говорю про метки а не категории).

В идеале возможность настроить, какие поля из контактов отображать в списке контактов было бы плюсом (так как иногда месседженер может быть использован как менеджер контактов, когда их >100 нужны какие то дополнительный инструменты, поиск, доп-поля и т.п.).

И не пытайтесь перегрузить месседженер социальными плюшками (не нужно из него делать фейсбук, как это пытаются сделать из скайпа).

---

Еще совет, архитектура скайпа более интересная, чем jabber, так как сервер — это фактически техническая часть, у скайпа это обычная транзитная нода а у jabber — специально выделенный сервис, который кто то должен настроить и поддержать (т.е. возможная точка отказа, мне например очень не нравится что jabber-сервера постоянно отваливаются). Как классическое решение — все ставят свой сервер (т.е. клиент фактически сервер),… но это будет уже другая архитектура. Рассмотрите ее получше.

[Exx-ks]

rPman, Возможно к вам обратиться за консультацией по данной тематике ?

[rPman]

Exx-ks, на тему разработки архитектуры месседженера?

[Exx-ks]

rPman, Да и еще пару вопросов можно обсудить в личке если у вас есть такая возможность

[rPman]

хабр

Answer 2

[YuriiVoitenko]

В классической теории информации, в той ее части, которая касается защиты, есть перечень атак на клиента и сеть в целом.
Приведу лишь несколько для того, чтоб более менее направить разработчиков в правильное русло, кое есть наука…
1. Атака типа man-in-the-middle
2. Атака повторением
3. Атака на протокол, анализ трафика
4. Отказ от обслуживания
Ну и ряд других…
Надо почитать умные книги — там все сказано.

Самый главный минус всей архитектуры выше состоит в том, что связка открытый-закрытый ключ, генерируются сервером!
Я бы предложил линковать в клиент библиотеку QCA и генерировать ключи локально, отдавая на сервер публичный ключ. Тогда сервер выступал бы только вроде публичной адресной книги для установления соединения между клиентами.

Comments

[bak]

Генерация ключа происходит на стороне клиента («Регистрация»: «cli: сгенерировать и сохранить открытый / закрытый ключи;». Просто у серверов тоже имеются свои открытые закрытые ключи как раз с целью предотвращение mim атак в процессе использования. С конкретной библиотекой и алгоритмами шифрования пока не определились.