Как сделать p2p мессенджер

Пишем свой мессенджер P2P

На фоне обсуждения будущего интернет мессенджеров и прочтения статьи «Почему ваш любимый мессенджер должен умереть», решил поделиться своим опытом создания P2P приложения для общения независимо от сторонних серверов. Точнее — это просто заготовка, передающая одно сообщение от клиента серверу, дальнейшее расширение функционала зависит только от Вашей фантазии.

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

Нам понадобится:
— один сервер с белым статическим IP адресом;
— 2 компьютера за NAT с типом соединения Full Cone NAT (либо 1 компьютер с 2-мя виртуальными машинами);
— STUN-сервер.

Full Cone NAT — это такой тип преобразования сетевых адресов, при котором существует однозначная трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт».

Вот, что мы можем прочесть о STUN-сервере на Wiki:

«Существуют протоколы, использующие пакеты UDP для передачи голоса, изображения или текста по IP-сетям. К сожалению, если обе общающиеся стороны находятся за NAT’ом, соединение не может быть установлено обычным способом. Именно здесь STUN и оказывается полезным. Он позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта.»

При решении задачи использовались следующие питоновские модули: socket, twisted, stun, sqlite3, os, sys.

Для обмена данными, как между Сервером и Клиентом, так и между Сервером, Клиентом и Сигнальным Сервером — используется UDP протокол.

В общих чертах механизм функционирования выглядит так:

Сервер STUN сервер
Клиент STUN сервер

Сервер Сигнальный Сервер
Клиент Сигнальный Сервер

1. Клиент, находясь за NAT с типом соединения Full Cone NAT, отправляет сообщение на STUN сервер, получает ответ в виде своего внешнего IP и открытого PORT;

2. Сервер, находясь за NAT с типом соединения Full Cone NAT, отправляет сообщение на STUN сервер, получает ответ в виде своего внешнего IP и открытого PORT;

При этом, Клиенту и Серверу известен внешний (белый) IP и PORT Сигнального Сервера;

3. Сервер отправляет на Сигнальный Сервер данные о своих внешних IP и PORT, Сигнальный Сервер их сохраняет;

4. Клиент отправляет на Сигнальный Сервер данные о своих внешних IP и PORT и id_destination искомого Сервера, для которого ожидает его внешний IP, PORT.

Сигнальный Сервер их сохраняет, осуществляет поиск по базе, используя id_destination и, в ответ, отдает найденную информацию в виде строки: ‘id_host, name_host, ip_host, port_host’;

5. Клиент принимает найденную информацию, разбивает по разделителю и, используя (ip_host, port_host), отправляет сообщение Серверу.

Приложения написаны на Python версии 2.7, протестированы под Debian 7.7.

Создадим файл server.py с содержимым:

Заполним соответствующие поля разделов: «Внешний IP и PORT СИГНАЛЬНОГО СЕРВЕРА» и «IP и PORT этого КЛИЕНТА».

Создадим файл client.py с содержимым:

Заполним соответствующие поля разделов: «Внешний IP и PORT СИГНАЛЬНОГО СЕРВЕРА» и «IP и PORT этого КЛИЕНТА».

Источник

Пишем мессенджер с открытым исходным кодом

Давным-давно в одной далекой стране была компания America Online. И был у нее удивительный частный Интернет за заборчиком, где вместо URL-ов были «keywords»: что-то среднее между адресом веб страницы и купленным ключевым словом в рекламе. Компании боролись за интересные ключевые слова, как сейчас борются за домены, а реклама выглядела так: «посетите нас во всемирной сети по адресу www.example.com, или наберите AOL Keyword: ‘banking'».

История имеет свойство повторяться. Сейчас роль Америки Онлайн играют основные мессенджеры: все они за заборчиками, несовместимы друг с другом, все изобретают свои keywords, желают схватить пользователя и уже никогда не отпускать. Компании не заинтересованы в открытости: более крупные игроки не желают делиться пользователями с более мелкими и уж тем более становиться открытыми. В результате невозможно послать сообщение даже из WhatsApp в Facebook Messenger, несмотря на то, что оба принадлежат одной компании. Да и пользователи ценят надежность и удобство выше абстрактной открытости, хотя многих раздражает, что часть друзей, например, в Telegram, часть в WhatsApp, а родители в Skype.

А вот роль открытого интернета, к сожалению, сегодня не играет никто. Ситуацию хочется изменить. Если XMPP не справился, может быть кто-то другой сможет? И тут рассказ про Tinode.

Что такое Tinode

Tinode — мессенджер с полностью открытым исходным кодом на Github. Все клиентские приложения (ReactJS и Андроид) лицензированы под Apache 2.0, для того, чтобы упростить создание коммерческих приложений на основе Tinode, сервер под GPL 3.0. Цель проекта — создать федерированный мессенджер, который прост и удобен как для пользователей, так и для операторов. Поставил — и все работает, как MySQL или Nginx. В долгосрочной перспективе цель проекта – создать открытую альтернативу существующим проприетарным мессенджерам, повторить в отношении мессенджеров то, что сделал Android в отношении операционных систем для мобильных телефонов.

Что он умеет

Поддержка множественных устройств.

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

Очевидно, что хранение информации пользователя на сервере подходит не всем, так как создает риски нежелательного доступа: чем больше копий данных хранится в разных местах, тем выше вероятность, что что-то пойдет не так. Для этого предусмотрена возможность эфемерных сообщений и сообщений, которые удаляются с сервера после доставки клиенту. Технически, существует и возможность не хранить контакты на сервере постоянно — клиент отправляет их на сервер в момент подключения (login), затем они удаляются после logout. Однако, авторы посчитали это непрактично сложным и не стали делать.

Онлайн статус

Трансляция онлайн/оффлайн статуса пользователя в мессенджерах воспринимается как что-то само собой разумеющееся, однако, это весьма тяжелая в реализации фича. Нужно, чтобы она «просто работала», предсказуемо и надежно. Надежность работы исключила генерацию статуса на клиенте, как это реализовано в некоторых XMPP приложениях. В случае Tinode, сервер генерирует онлайн статус и рассылает по адресной книге, что, опять же, требует хранения контактов на сервере и их синхронизацию с клиентскими приложениями.

Простота протокола

Протокол хотелось сделать таким, чтобы кривая обучаемости была пологой – не нужно знать всего, чтобы начать. Спецификация получилась очень компактной: 10 запросов клиента, 5 ответов сервера. Например, по сравнению с 200+ страницами только core XMPP, не считая extensions, это почти записка на салфетке.

Представление данных отделено от сетевого протокола. Протокол лишь требует определенную структуру данных, но не требует, чтобы они передавались по сети каким-то определенным образом. Сейчас сервер поддерживает JSON по websocket и long polling, c TLS и без, плюс gRPC по TCP. Поддержка gRPC была реализована одним разработчиком за две недели, включая написание текстового клиента на Питоне. Добавление поддержки иных форматов данных и протоколов, например, MessagePack или Noise, вряд ли займет намного больше.

Расширяемость

С одной стороны, хочется, чтобы все работало сразу, например, чтобы основной функционал был сравним с WhatsApp и Telegram прямо из коробки. С другой, потребности у людей разные и нужно иметь возможность расширять функционал. Поиск баланса похож на выбор между монолитной архитектурой и микросервисами: нежелательно иметь неизменяемый монолит, и, аналогично, плохо получить получить зоопарк микросервисов, управление которыми превращается в отдельную задачу.

Было принято решение разделить функционал на три части — основной, сетевой и вспомогательный. Основной — это то, что позволяет Tinode выполнять основную функцию — пересылать сообщения. Сетевой — функционал взаимодействия в серверами, как формат передаваемых данных и сетевой протокол. Вспомогательный — то, что решает чью-то локальную задачу, например, поддержка конкретной базы данных в качестве бэкенда или какой-то метод авторизации, но никак не влияет на другие сервера или пользовательские приложения. Основной функционал реализован в основном коде. Сетевой функционал выделен, но также хранится в основном репозитории для того, чтобы по возможности избежать создания несовместимых серверов. Вспомогательный реализован в виде плагинов — компилируемых Go интерфейсов (поддержка разных баз данных, разных авторизаторов, пуш нотификации, валидаторы по емейл или телефону, поддержка каптчи и т.п.) и gRPC endpoints (чатбот и поисковый интерфейс).

Прочее

Почему Go?

Сервер для мессенджера по сути роутер: получает сообщение из одного канала, как-то его обрабатывает, затем передает в другой канал или каналы. Go (как и Erlang, но это уже другая история) идеально подходит для создания такого функционала т.к. содержит примитивы goroutine и chan, делающие организацию потоков и обмен данными между ними эффективным и простым.

Безусловно, роутер можно написать и на C/C++, и на Java. Однако, при прочих равных, код скорее всего получится более сложным и потребует больших усилий для избежания дедлоков.

А что потом?

Федерация

Одна из основных задач для Tinode на ближайший год — создание платформы для федерации. Так, чтобы любой желающий мог запустить свой Tinode сервер, который бы мог обмениваться сообщениями с любым другим сервером, точно так, как это возможно с емейлом. Уже сейчас возможна кластеризация серверов. Сетевой обмен между сервером и клиентами идет по TLS websocket, что для внешного наблюдателя мало отличимо от простого HTTPS трафика.

Публичный DNS, вероятно, будет использоваться, по крайней мере первоначально. Однако, в будущем поиск чат-серверов будет осуществляться также, как это сделано в Bittorrent — при помощи DHT, распределенной хеш таблицы.

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

Репутация и распределенное принятие решений

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

• Криптографическая идентификация сервера-отправителя.
  Изначально, SMTP вообще не предполагал какой-либо идентификации отправителя. Не стоит снова наступать на эти грабли. Каждый сервер, желающий установить контакт, будет представлен криптографическим сертификатом. «Ну да», скажете вы, «я сейчас нагенерю 100500 сертификатов и каждый раз буду представляться новым чистым сервером». И будете правы. Поэтому следующий пункт.
• Распределенный учет репутации.
  Когда к нам стучится новый, неизвестный сервер-отправитель, мы сделаем запрос к известным серверам с просьбой сообщить рейтинг нового сервера. И в зависимости от ответа установим, например, скорость, с которой новый сервер может посылать нам сообщения.

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

Шифрование

Ну а как же в наши дни без шифрования сообщений? Чаты между двумя людьми, вероятно, будут шифроваться OTR. С групповыми чатами пока непонятно. Все известные схемы шифрования групповых чатов либо имеют значительный недостатки, либо тяжеловесны и сложны в реализации. Также, не очевидно, насколько важно шифрование групповых чатов: «Если тайну знают двое – это уже не тайна, а если трое – это уже базар.»

Источник

Новая жизнь для XMPP. Делаем мессенджер, который не получится заблокировать

Идея сделать независимый от корпораций P2P мессенджер не нова, однако разработка нового протокола и клиентских приложений для него достаточно дорогой и долгий процесс. А что, если использовать старый добрый XMPP, в котором уже все давно продумано и запилено?

Но это же не настоящий peer-to-peer, скажете вы, для работы XMPP нужен собственный сервер и домен. Это так, но мы можем запустить сервер на локалхосте, а для связи с серверами других пользователей использовать скрытый сервис в виртуальной сети I2P. Использование I2P избавит нас от необходимости платить за домен с хостингом, а так же защитит наши коммуникации от преступной онлайн-слежки.

Таким образом, получаем:

• Гибридный P2P мессенджер, который можно запускать и на пользовательских устройствах, и на полноценном сервере.
• Фичи, которых не хватает другим P2P мессенджерам: оффлайн сообщения, хранение контактов и истории «в облаке», работа нескольких клиентов с одним аккаунтом.
• Готовые клиентские приложения на любой вкус.
• За счет использования I2P, неуязвим для различных *надзоров (сори за мат).

Приступим же к реализации.

Установка I2P и создание серверного тоннеля

В данном руководстве, в качестве I2P роутера будем использовать легковесный C++ клиент i2pd. Инструкция по установке есть в документации.

После установки создаем серверный I2P туннель — это виртуальный адрес, по которому наш XMPP сервер будет доступен для остального мира. В файл tunnels.conf дописываем следующие строки:

Если планируется использование только на локалхосте, секцию prosody-c2s можно не добавлять. Перезагружаем i2pd, чтобы применить настройки. Ищем I2P адрес созданного туннеля в веб-консоли http://127.0.0.1:7070/ на странице I2P tunnels .

Можно так же узнать b32 адрес нового туннеля, грепнув логи:

Сохраните этот xxx.b32.i2p адрес, это будет домен для вашего XMPP сервера.

Установка и настройка XMPP сервера

В качестве XMPP сервера будем использовать prosody, он самый легкий и под него есть готовый модуль для работы через I2P. Установка описана в официальной документации, в Ubuntu делается элементарно apt install prosody .

Для работы mod_darknet нужна lua библиотека bit32. Если у вас lua версии меньше 5.2 (скорее всего) выполняем apt install lua-bit32 .

Устанавливаем модуль mod_darknet . Он нужен, чтобы prosody делал исходящие соединения через Socks5 сервер i2pd. Скачиваем этот файл в директорию модулей prosody, обычно это /usr/lib/prosody/modules .

Теперь редактируем конфиг /etc/prosody/prosody.cfg.lua. Замените xxx.b32.i2p на свой адрес:

Последний шаг в настройке prosody — генерация сертификатов шифрования. В никсах это делается так:

Перезагрузите сервер prosody для применения настроек.

Тут нужно небольшое отступление. В сети I2P любые соединения зашифрованы сквозным шифрованием и, казалось бы, дополнительное шифрование тут излишне. Но, на практике, оказалось проще сгенерировать ключи, чем пытаться настроить все программы на использование открытого текста. Вы можете попробовать, но я вас предупреждал.

Создание аккаунтов и подключение клиентов

Добавляем админский аккаунт:

Теперь настраиваем XMPP клиент (например Pidgin).

Если вы подключаетесь к локалхосту, то в настройках клиента указываем подключение к серверу 127.0.0.1 порт 5222.

Если подключаетесь к серверу удаленно через I2P, то указывайте в настройках прокси Socks5 127.0.0.1:4447.

Источник