Пока правообладатели собираются заблокировать централизованный Telegram, сообщество пользователей распределенного мессенджера Tox растет. Сегодня, согласно статистике сайта www.toxstats.com, Россия занимает второе место после США по количеству пользователей отставая всего на какие-то 30-50 узлов.
В данной публикации я бы хотел рассказать про распределенную природу данного мессенджера, общие принципы работы DHT-сети Tox, а так же как "догнать и перегнать Америку" по количеству нод.
Каждая нода Tox определяется IP адресом, номером порта и публичным 256-и битным ключом. Существует два условных вида нод:
Публичный ключ ноды используется для шифрования пакетов передаваемых этой ноде. Пакеты расшифровываются на стороне ноды при помощи 256-и битного приватного ключа. Для передачи DHT-пакетов используется протокол UDP.
Для «входа» в сеть Tox достаточно иметь связность с любой нодой Tox, которая уже находится в сети. Обычно для этого используется список из известных bootstrap-нод в сети интернет. Дополнительно библиотека libtoxcore использует отправку пакетов на широковещательные адреса, что позволяет подключиться к сети Tox не имея выхода в интернет (при условии, что в вашем сегменте сети есть необходимая нода). И даже без выхода в интернет две и более ноды Tox образуют изолированную сеть Tox, позволяющую взаимодействовать локальным клиентам.
Поскольку каждая нода Tox имеет уникальный идентификатор в виде публичного ключа, то отношения между двумя любыми нодами можно выразить искусственной метрикой на базе этих ключей. Этой метрикой является расстояние между ключами. Расстояние вычисляется как сложение по модулю 2 (побитовый XOR) между двумя ключами и интерпретируется как беззнаковое целое.
Из свойств операции XOR вытекает, что нулевое расстояние может быть только между одним и тем же ключом (ключом ноды), а половина всего пространства ключей по отношению к ключу ноды будет иметь максимально возможное расстояние — с некоторой условностью ноды с такими ключами можно считать «недостижимыми» и взаимодействие с подобными нодами будет достаточно редким событием.
Процесс входа в сеть Tox начинается с отправки пакета "Nodes request" известной bootstrap-ноде (одной или нескольким), где содержимое пакета представляет собой разыскиваемый публичный ключ. Нода, получившая пакет «Nodes request», ищет среди известных ей публичных ключей (кроме своего собственного и запрашиваемого) ключи с наименьшим расстоянием от разыскиваемого и отвечает пакетом "Nodes response", содержащим от 1 до 4 найденных ключей и соответствующих им нод (IP/порт). Итеративно повторяя запросы «Nodes request» к нодам из ответа клиент-нода может найти другую ноду с минимальным расстоянием от искомого ключа (параллельно получая информацию о существующих промежуточных нодах).
Если в качестве искомого ключа клиент-нода будет указывать свой собственный ключ, то найденные ноды с минимальным расстоянием между ключами будут ее «соседями». Если в качестве искомого ключа клиент-нода будет указывать ключ запрашиваемой ноды, но найденные ноды буду соседями опрашиваемой ноды — так работает подсчет статистики сети.
Живость каждой известной ноды проверяется периодической отправкой пакета "Ping request", на который получатель должен ответить пакетом "Ping response". Дополнительно с некоторой периодичностью клиент-нода отправляет случайной (из известных) ноде пакет «Nodes Request» для получения информации об изменениях в DHT-сети. Неотвечающие ноды удаляются из списка известных по истечении таймаута.
Необходимость частой отправки пакета «Ping request» для большого списка известных нод приводит к неоправданной нагрузке на сеть. В то же самое время сохранение информации только о ближайших соседях будет приводить к увеличению времени поиска неизвестной ноды. Для достижения баланса в библиотеке libtoxcore введено понятие индекса ключа — это индекс первого отличающегося бита ключа по отношению к ключу ноды. Для каждого нового ключа вычисляется его индекс и для каждого индекса ядро сохраняет до 8 ключей вытесняя ключи с наибольшим расстоянием. Дополнительно ядро хранит 8 ключей ближайших соседей с тем же алгоритмом вытеснения.
В текущей реализации libtoxcore длина индекса ограничена 128 «корзинами», что при определенном везении позволяет каждой ноде хранить информацию о 1024 нодах (до некоторого времени в прошлом, пока сеть была очень-очень маленькой, использовалось 32 корзины и 190 нод соответственно). При минимальном размере пакета в 82 байта («Ping request») и опросе каждой ноды раз в 60 секунд, получаем трафик в ~22Kbit при максимальной загрузке индекса.
Из правила вычисления индекса корзины так же следует, что чем меньше расстояние между двумя ключами, тем больший индекс будет иметь ключ и тем меньше будет вероятность встретить такой ключ. В реализации библиотеки libtoxcore ключи с индексом более 127 или становятся «соседями» или попадают в 128-ю корзину в зависимости от расстояния.
Таким образом каждая нода сети Tox поддерживает эффективную связность не только с соседями, но и с нодами на «дальних рубежах» соблюдая баланс между нагрузкой на сеть и временем поиска любой другой ноды.
В отличии от DHT-нод, вся информация о которых известна или может быть получена любым клиентом DHT-сети Tox, клиентские приложения скрыты от стороннего наблюдателя — простого знания ToxID контакта (содержащего его публичный ключ) недостаточно для того, чтобы установить местонахождение этого контакта. Для соединения двух приложений Tox используется механизм луковой маршрутизации («onion routing»).
Механизм установления связи между двумя клиентами можно представить следующим образом. Два клиента (A и Z) анонсируют свой публичный ключ на ближайших (для своего публичного ключа) нодах через три случайные промежуточные DHT-ноды, каждая из которых знает только своих соседей по маршрутизации пакета, но не может прочитать содержимое пакета.
Второй клиент (Z), желающий соединиться с первым (A), так же через три случайные DHT-ноды делает запрос на установку соединения на ближайшую к искомому ключу (A) ноду, которая знает об анонсе первого клиента и маршруте, по которому требуется передать запрос от второго клиента.
Первый клиент (A) в случае принятия запроса на установку соединения, проделывает обратную операцию к ближайшей DHT-ноде второго клиента (Z).
После обмена информацией о метоположении друг-друга и временных ключах клиенты могут соединиться напрямую.
Если клиенты не желают делиться информацией о своем местоположении даже со своими контактами, они могут использовать ноды поддерживающие TCP-relay через прокси типа Tor.
Особенностью TCP-релеев является то, что они пытаются использовать «широко-известные» («well-known») прты: 443 (HTTPS) и 3389 (RDP), что затрудняет их отслеживание и идентификацию.
Для защиты распределенной сети от большинства известных угроз можно использовать простое эмпирическое правило — чем больше в сети благонадежных узлов, тем сеть устойчивее к возможным атакам. При чем для некоторых видов атак нейтрализация каждого благонадежного узла требует десяток-другой атакующих.
Исходя из описания выше, если вы пользуетесь любым клиентом Tox, то вы уже являетесь нодой сети (при этом ваша нода никак не связана с вашим ToxID за исключением того, что оба находятся на одном хосте). Если же вы пока не пользуетесь Tox, но желаете помочь проекту, вы можете установить bootstrap-ноду на подконтрольных вам серверах и компьютерах — она не потребляет много трафика или вычислительных ресурсов (в отличии от старых добрых времен Folding@home).
Детальное описание процесса сборки и установки ноды можно найти по ссылке "Вливаемся в tox-сообщество или установка ноды за 5 минут". Однако я постарался максимально упростить данный процесс собрав пакет tox-easy-bootstrap для большинства популярных дистрибутивов Linux.
Для установки пакета tox-easy-bootstrap перейдите по ссылке на репозитории проекта, выберете свой дистрибутив и следуйте простым инструкциям по добавлению репозитория и установке пакета в вашу систему.
Установщик пакета автоматически получит актуальный список публичных bootstrap-нод, создаст конфигурационный файл /etc/tox-bootstrapd.conf и запустит демона tox-bootstrapd под отдельным системным пользователем. Раз в неделю по cron специальный скрипт будет обновлять список публичных bootstrap-нод в конфигурационном файле, по этому вам не нужно будет беспокоиться о его актуальности в случае перезагрузки сервера — «поставил и забыл».
Для случаев, если на сервере используется «нормально закрытый» firewall вам может потребоваться внести разрешающие правила для входящего трафика на UDP:33445 и TCP:3389,33445 (порт TCP:443 не используется, т.к. процесс запускается под непривилегированным пользователем) — во избежании потенциальных «диверсий» эту часть я автоматизировать не стал:
Конфигурационный файл пакета /etc/tox-easy-bootstrap.conf позволяет изменить настройки по умолчанию (которые подходят для большинства случаев) и, например, «перелинковать» несколько своих частных нод на случай недоступности всех публичных — как было описано выше, достаточно связности с любой одной нодой в сети для выхода в сеть второй ноды.
Вопрос о том, публиковать ли данные о своей ноде в списке публичных нод остается на ваше личное усмотрение — с технической точки зрения частная нода ни чем не отличается от публичной.
Протокол Tox позволяет не только писать ботов, обмениваться сообщениями, файлами или совершать аудио-видео вызовы, но и использовать его в качестве базового протокола для других сетевых задач.
Так, например, проекты tuntox и toxvpn используют протокол Tox для организации P2P соединения хостов за NAT пополняя список Full-Mesh VPN решений.
Существуют экспериментальные проекты toxmail для организации почтового сообщения, toxscreen для получения доступа к удаленному рабочему столу, toxshare для файлообмена между доверенным кругом лиц.
Для экспериментов по написанию новых приложений вы можете использовать обертки (поддерживаемые и не очень) для других языков и платформ: python, rust, go, node.js — практически неограниченный простор для новых идей и проектов.
В данной публикации я бы хотел рассказать про распределенную природу данного мессенджера, общие принципы работы DHT-сети Tox, а так же как "догнать и перегнать Америку" по количеству нод.
Введение
Каждая нода Tox определяется IP адресом, номером порта и публичным 256-и битным ключом. Существует два условных вида нод:
- Bootstrap-нода — нода, которая обслуживает работу сети, но не взаимодействует напрямую с пользователем.
- Клиент Tox — нода, которая помимо обслуживания работы сети, выполняет какую-либо дополнительную работу (бот, мессенджер). При этом клиент и нода используют разные пары ключей.
Публичный ключ ноды используется для шифрования пакетов передаваемых этой ноде. Пакеты расшифровываются на стороне ноды при помощи 256-и битного приватного ключа. Для передачи DHT-пакетов используется протокол UDP.
Для «входа» в сеть Tox достаточно иметь связность с любой нодой Tox, которая уже находится в сети. Обычно для этого используется список из известных bootstrap-нод в сети интернет. Дополнительно библиотека libtoxcore использует отправку пакетов на широковещательные адреса, что позволяет подключиться к сети Tox не имея выхода в интернет (при условии, что в вашем сегменте сети есть необходимая нода). И даже без выхода в интернет две и более ноды Tox образуют изолированную сеть Tox, позволяющую взаимодействовать локальным клиентам.
Самоорганизация DHT-сети
Поскольку каждая нода Tox имеет уникальный идентификатор в виде публичного ключа, то отношения между двумя любыми нодами можно выразить искусственной метрикой на базе этих ключей. Этой метрикой является расстояние между ключами. Расстояние вычисляется как сложение по модулю 2 (побитовый XOR) между двумя ключами и интерпретируется как беззнаковое целое.
Из свойств операции XOR вытекает, что нулевое расстояние может быть только между одним и тем же ключом (ключом ноды), а половина всего пространства ключей по отношению к ключу ноды будет иметь максимально возможное расстояние — с некоторой условностью ноды с такими ключами можно считать «недостижимыми» и взаимодействие с подобными нодами будет достаточно редким событием.
Процесс входа в сеть Tox начинается с отправки пакета "Nodes request" известной bootstrap-ноде (одной или нескольким), где содержимое пакета представляет собой разыскиваемый публичный ключ. Нода, получившая пакет «Nodes request», ищет среди известных ей публичных ключей (кроме своего собственного и запрашиваемого) ключи с наименьшим расстоянием от разыскиваемого и отвечает пакетом "Nodes response", содержащим от 1 до 4 найденных ключей и соответствующих им нод (IP/порт). Итеративно повторяя запросы «Nodes request» к нодам из ответа клиент-нода может найти другую ноду с минимальным расстоянием от искомого ключа (параллельно получая информацию о существующих промежуточных нодах).
Если в качестве искомого ключа клиент-нода будет указывать свой собственный ключ, то найденные ноды с минимальным расстоянием между ключами будут ее «соседями». Если в качестве искомого ключа клиент-нода будет указывать ключ запрашиваемой ноды, но найденные ноды буду соседями опрашиваемой ноды — так работает подсчет статистики сети.
Живость каждой известной ноды проверяется периодической отправкой пакета "Ping request", на который получатель должен ответить пакетом "Ping response". Дополнительно с некоторой периодичностью клиент-нода отправляет случайной (из известных) ноде пакет «Nodes Request» для получения информации об изменениях в DHT-сети. Неотвечающие ноды удаляются из списка известных по истечении таймаута.
Необходимость частой отправки пакета «Ping request» для большого списка известных нод приводит к неоправданной нагрузке на сеть. В то же самое время сохранение информации только о ближайших соседях будет приводить к увеличению времени поиска неизвестной ноды. Для достижения баланса в библиотеке libtoxcore введено понятие индекса ключа — это индекс первого отличающегося бита ключа по отношению к ключу ноды. Для каждого нового ключа вычисляется его индекс и для каждого индекса ядро сохраняет до 8 ключей вытесняя ключи с наибольшим расстоянием. Дополнительно ядро хранит 8 ключей ближайших соседей с тем же алгоритмом вытеснения.
В текущей реализации libtoxcore длина индекса ограничена 128 «корзинами», что при определенном везении позволяет каждой ноде хранить информацию о 1024 нодах (до некоторого времени в прошлом, пока сеть была очень-очень маленькой, использовалось 32 корзины и 190 нод соответственно). При минимальном размере пакета в 82 байта («Ping request») и опросе каждой ноды раз в 60 секунд, получаем трафик в ~22Kbit при максимальной загрузке индекса.
Из правила вычисления индекса корзины так же следует, что чем меньше расстояние между двумя ключами, тем больший индекс будет иметь ключ и тем меньше будет вероятность встретить такой ключ. В реализации библиотеки libtoxcore ключи с индексом более 127 или становятся «соседями» или попадают в 128-ю корзину в зависимости от расстояния.
Таким образом каждая нода сети Tox поддерживает эффективную связность не только с соседями, но и с нодами на «дальних рубежах» соблюдая баланс между нагрузкой на сеть и временем поиска любой другой ноды.
Клиенты DHT-сети
В отличии от DHT-нод, вся информация о которых известна или может быть получена любым клиентом DHT-сети Tox, клиентские приложения скрыты от стороннего наблюдателя — простого знания ToxID контакта (содержащего его публичный ключ) недостаточно для того, чтобы установить местонахождение этого контакта. Для соединения двух приложений Tox используется механизм луковой маршрутизации («onion routing»).
Механизм установления связи между двумя клиентами можно представить следующим образом. Два клиента (A и Z) анонсируют свой публичный ключ на ближайших (для своего публичного ключа) нодах через три случайные промежуточные DHT-ноды, каждая из которых знает только своих соседей по маршрутизации пакета, но не может прочитать содержимое пакета.
Второй клиент (Z), желающий соединиться с первым (A), так же через три случайные DHT-ноды делает запрос на установку соединения на ближайшую к искомому ключу (A) ноду, которая знает об анонсе первого клиента и маршруте, по которому требуется передать запрос от второго клиента.
Первый клиент (A) в случае принятия запроса на установку соединения, проделывает обратную операцию к ближайшей DHT-ноде второго клиента (Z).
После обмена информацией о метоположении друг-друга и временных ключах клиенты могут соединиться напрямую.
Если клиенты не желают делиться информацией о своем местоположении даже со своими контактами, они могут использовать ноды поддерживающие TCP-relay через прокси типа Tor.
Особенностью TCP-релеев является то, что они пытаются использовать «широко-известные» («well-known») прты: 443 (HTTPS) и 3389 (RDP), что затрудняет их отслеживание и идентификацию.
«Догнать и перегнать Америку»
Для защиты распределенной сети от большинства известных угроз можно использовать простое эмпирическое правило — чем больше в сети благонадежных узлов, тем сеть устойчивее к возможным атакам. При чем для некоторых видов атак нейтрализация каждого благонадежного узла требует десяток-другой атакующих.
Исходя из описания выше, если вы пользуетесь любым клиентом Tox, то вы уже являетесь нодой сети (при этом ваша нода никак не связана с вашим ToxID за исключением того, что оба находятся на одном хосте). Если же вы пока не пользуетесь Tox, но желаете помочь проекту, вы можете установить bootstrap-ноду на подконтрольных вам серверах и компьютерах — она не потребляет много трафика или вычислительных ресурсов (в отличии от старых добрых времен Folding@home).
Детальное описание процесса сборки и установки ноды можно найти по ссылке "Вливаемся в tox-сообщество или установка ноды за 5 минут". Однако я постарался максимально упростить данный процесс собрав пакет tox-easy-bootstrap для большинства популярных дистрибутивов Linux.
Для установки пакета tox-easy-bootstrap перейдите по ссылке на репозитории проекта, выберете свой дистрибутив и следуйте простым инструкциям по добавлению репозитория и установке пакета в вашу систему.
Установщик пакета автоматически получит актуальный список публичных bootstrap-нод, создаст конфигурационный файл /etc/tox-bootstrapd.conf и запустит демона tox-bootstrapd под отдельным системным пользователем. Раз в неделю по cron специальный скрипт будет обновлять список публичных bootstrap-нод в конфигурационном файле, по этому вам не нужно будет беспокоиться о его актуальности в случае перезагрузки сервера — «поставил и забыл».
Для случаев, если на сервере используется «нормально закрытый» firewall вам может потребоваться внести разрешающие правила для входящего трафика на UDP:33445 и TCP:3389,33445 (порт TCP:443 не используется, т.к. процесс запускается под непривилегированным пользователем) — во избежании потенциальных «диверсий» эту часть я автоматизировать не стал:
-A INPUT -p tcp --dport 3389 -j ACCEPT
-A INPUT -p tcp --dport 33445 -j ACCEPT
-A INPUT -p udp --dport 33445 -j ACCEPT
Конфигурационный файл пакета /etc/tox-easy-bootstrap.conf позволяет изменить настройки по умолчанию (которые подходят для большинства случаев) и, например, «перелинковать» несколько своих частных нод на случай недоступности всех публичных — как было описано выше, достаточно связности с любой одной нодой в сети для выхода в сеть второй ноды.
Вопрос о том, публиковать ли данные о своей ноде в списке публичных нод остается на ваше личное усмотрение — с технической точки зрения частная нода ни чем не отличается от публичной.
Заключение
Протокол Tox позволяет не только писать ботов, обмениваться сообщениями, файлами или совершать аудио-видео вызовы, но и использовать его в качестве базового протокола для других сетевых задач.
Так, например, проекты tuntox и toxvpn используют протокол Tox для организации P2P соединения хостов за NAT пополняя список Full-Mesh VPN решений.
Существуют экспериментальные проекты toxmail для организации почтового сообщения, toxscreen для получения доступа к удаленному рабочему столу, toxshare для файлообмена между доверенным кругом лиц.
Для экспериментов по написанию новых приложений вы можете использовать обертки (поддерживаемые и не очень) для других языков и платформ: python, rust, go, node.js — практически неограниченный простор для новых идей и проектов.
Ссылки
- toxstats.com, tox.viktorstanchev.com, stats.letstox.com — статистика сети Tox.
- Проект спецификации протокола tox — toktok.github.io.
- Проект для сборки бинарных версий клиентов и библиотек — tox.pkg на github.
- tox.chat — официальный сайт проекта Tox.
Комментарии (40)
phantom-code
28.03.2016 12:08+1Из-за природы Tox-сети, в ней невозможно нормально реализовать offline-сообщения. Для меня очень важна данная функциональность, поэтому при всей моей любви к tox, я им пользоваться не могу.
WEBIVAN
28.03.2016 12:47Пока не будет нормальных удобных клиентов с полноценным функционалом, все преимущества протокола можно забыть ибо нормально пользоваться невозможно, а пока имеем кучу глючных клиентов с сильно кастрированным функционалом для некоторых платформ.
gmelikov
28.03.2016 14:03+1Поздравляю, наверное, с помощью данной статьи в настоящий момент разрыв по количеству пользователей в России всего лишь на 1 меньше чем в США (544 vs 545 соответственно)!
Осталось только мне зайти в tox=) Жаль пароль забыл...
dimatl
28.03.2016 15:21+1Нужен клиент для роутеров, чтобы сидел в инвизе и принимал офлайновые сообщения и раздавал на вошедшие в сеть устройства. И самое главное полноценные клиенты для мобильных устройств.
Daytar
28.03.2016 16:28И самое главное полноценные клиенты для мобильных устройств.
Глупо ждать полноценные клиенты когда в core-либе периодически ломают API, недавно как раз были изменения в A/V API, сейчас вот почти готова новая реализация групп-чатов с новым API и протоклом.
antonbatenev
28.03.2016 16:48Изменения в API известны задолго до их вливания в ядро. Так, например, к новому ToxAV были готовы все клиенты и переключились в течении суток. Я бы не назвал это "ломают".
Проблема с мобильными клиентами, как мне кажется, немного в другом — людям, которым интересен проект, не особо интересна мобильная версия. Людям, которым интересна мобильная версия, не особо интересен проект. И тех и других по своему можно понять.
ZoomLS
28.03.2016 16:28Tox хорошая вещь, особенно когда допилят. И сейчас бы пользовался. вот только, а как пользоваться одним аккаунтом на нескольких устройствах?
Komei
29.03.2016 00:13А нужно ли это? Очень вероятно что проблему нескольких аккаунтов можно было бы решить, сделав использование нескольких сразу удобным (группы аккаунтов или что-то такое). Да, история не синхронизируется. Но, во-первых это плата за безопасность, а во-вторых без этого вполне можно жить (особенно если предусмотрена нормальная ручная синхронизация: я на компе нажимаю на сообщении «синхронизовать с мобильным аккаунтом» и готово). Короче нужно делать не «так как в скайпе», а так, чтобы было удобно. Хотя оно и будет иначе из-за другой природы сети.
ZoomLS
29.03.2016 12:15Скорее всего вы меня не так поняли. Допустим на одном ПК установим Tox-клиент, а потом на втором ПК тоже. Но как на них выходя в сеть Tox, авторизироваться в одном и том же аккаунте? Я не имею ввиду, что сидеть сразу с двух. А только с одного в один момент времени.
Komei
29.03.2016 20:19Мой ответ предполагал что это вам просто не надо. Сама концепция решает это по другому. Как пример (возможно сырой): под именем пользователя в списке контактов могут скрываться несколько аккаунтов и сообщения посылаются на все из них (хотя реально это должно быть гибко, т.к. ту информацию что я доверяю для обработки на ПК, я могу не доверять обрабатывать на мобилке). Над конкретной реализацией нужно хорошенько подумать чтобы сбалансировать удобство/безопасность/нагрузку на сеть.
nlykl
29.03.2016 00:54Жаль, что нет версии для Debian arm. И я правильно понимаю, что сама по себе ваша сборка порт в роутере не пробрасывает?
shara
Это всё здорово, но
Рад бы использовать для общения с семьёй, продвигать по работе, но на текущем этапе оно не пригодно ни для чего, кроме общения гиков.
serf
> Что делать с оффлайн сообщениями?
Как вы себе это представляете в без-серверной архитектуре?
> Как пользоваться на нескольких устройствах?
Из той же серии, нет ведь сервера для синхронихации между клиентами.
Если вам нужно что-то с центральным сервером, то зачем тогда смотреть на Tox.
EndUser
1) Как у Шкапа — оффлайн сообщения висят в исходящих, пока оба не окажутся в онлайне. Понимаю, криво, но таки.
2) Разве невозможно подвязать двух клиентов на специфических условиях, чтобы обменялись историями?
Но, на самом деле меня интересует какой SLA у Tox — процент потерь «пинга», собственно время «пинга». А то я видал как-то СМС «с новым годом» в феврале, что не укладывается в моё понимание техники СМС.
И маскировка трафика против цензоров Tor, как такового, есть/будет?
В дальнейшем, конечно, потребуются расширенные функции передачи сообщений, ставших де-факто стандартом, например, передача файлов.
Я вот так осознаю разницу между Proof of Conception и популярным End User продуктом.
ars_ivanov
Передача файлов давно есть. А вот маскировка — это интересно.
antonbatenev
Так оно сейчас и происходит в некоторых клиентах.
В теории да, но на практике это сильно будет усложнять протокол без добавления к-л гарантий.
Чем больше мощность сети, тем надежней ее работа. Точных цифр никто никогда сказать не сможет ввиду самой природы сети, но на данный момет все работает вполне себе быстро и относительно надежно.
Тут не совсем понятно что имеется ввиду. Весь трафик Tox всегда шифруется, номера портов владелец ноды волен выбирать любые, маршруты Tor периодически меняются.
OldFisher
Исхитриться-то как-нибудь можно. Например, остающиеся в онлайне клиенты могли бы хранить сообщения (скажем, с некоторым таймаутом) для дальнейшей передачи получателю и перекидывать их другим при плановом выходе из сети. Для повышения надёжности можно ввести дублирование (скажем, кто-то оказывается "главным хранителем" сообщения и назначает нескольких дублёров, при внезапном выходе дублёров из сети назначают новых дублёров, при уходе главхранителя им становится один из дублёров). Если сохранять сообщения в локальном хранилище и возобновлять бдение при возвращении в онлайн, можно будет дополнительно защититься от потери сообщения при внезапном выпадении сразу всех хранителей.
SEVENID
И, таким образом, у нас будет очень много ненужного, даже паразитного, трафика, тем более, если в сообщении содержится какой-нибудь тяжёлый файл. Объёмы «хранителей», «дублёров» и количество одновременных соединений небесконечны, что предоставляет прекрасную возможность для атаки на всю сеть разом, используя всего одного атакующего, если я всё правильно понял.
AllexIn
Никто и не предлагает файлы в оффлайн передавать. Мало какие IM это позволяют, да и не нужно это.
А вот передачу сообщений по предложенному механизму вполне можно сделать. Объем трафика врядли увеличится значительно, т.к. много сообщений никто в оффлайн не отправляют. Плюс если сделать срох хранения небольшим — скажем 72 часа как у СМС — сеть будет чистится.
В тоже время даже если хранителей не будет в результате атаки или по любой другой причине — когда автор выйдет в онлайн, клиент увидит что сообщение до сих пор не доставлено — отправит его повторно.
Randl
Гарантии получается все равно нет — если уходишь в оффлайн надолго — гадай доставлено или нет. С дублерами и хранителями тоже самое — гарантировать что они все не уйдут в оффлайн быстрее передачи сообщения невозможно. Плюс можно спамить гигабайтами текста, забивая память.
То есть опять таки нужна супернода (сервер) для хранения сообщений, чтоб хоть какие-то гарантии были.
Вариант пересылать когда оба в онлайне — это уже задача клиента, а не протокола.
Т.е. на взгляд элементарная задача, но с требованиями а). распределенности б). гарантированной доставки сообщения решить ее далеко не просто.
AllexIn
Сообщение будет гарантированно доставлено. Например, когда автор выйдет в онлайн.
Ну это же не интересные доводы. Из разряда: не более 100 килобайт текста от одного автора.
В конце, концов, если ТАК важна доставка в онлайн — делается личный "хранитель" на своем сервере, который работает хранителем только для вас.
Или же арендуется услуга такого хранителя предоставляемого кем-то другим.
Вот только не надо решать это через централизованные сервера, как в случае со скайпом сделали.
antonbatenev
"Хранитель" и будет этим центральным сервером. Сейчас ничего не мешает взять консольный клиент и запустить его на своем выделенном сервере — клиент будет 24х7 в онлайне, а уж чем забирать с него историю и как через него отправлять сообщения — это вопрос не сильно сложный технологически.
AllexIn
Центральный сервер — это устройство, которое:
1) необходимо для работы
2) находится в ведомстве конкретной группы людей
Очевидно, что хранитель оба эти требования не удовлетворяет. Он может принадлежать кому угодно и не нужен для работы. Лишь дополнительный сервис.
Технически плевое дело.
Правда концепция хранителей позволит передавать свои сообщения левым людям, не заморачиваясь с установкой личного сервера, в отличии от предложенного варианта с клиентом в вечном онлайне.
Randl
Такой функционал уже имеется в клиентах. Это гарантия со стороны клиента а не протокола.
С таким же успехом можно просто не выходить из Tox на своем компе и оставить его запущенным.
Попробуйте на досуге придумать метод гарантированной доставки оффлайн сообщения без супернод (==хранитель который всегда онлайн == зависимость от владельца этой ноды). Именно оффлайн, а не доставлять когда оба онлайн (это, как мы сказали, уже есть)
thousandsofthem
Хранить в DHT сети (при условии что это часть протокола конечно)? Т е данные размазаны по куче разных клиентских устройств. Но имхо лучше так хранить вещи вроде списка контактов, метаинформации
Randl
Хранить у всех пользователей все ожидающие сообщения? Куча памяти.
У части? У какой? А если они уходят в оффлайн — копировать другим или как? Слишком маленькая часть — есть вероятность что все уйдут в оффлайн, слишком большая — слишком много места будут занимать эти сообщения, тем более если хранить их вечно. Не вечно? А сколько тогда? И т.д.
thousandsofthem
Хранить можно и на диске, зарезервировав сколько-там места, например 50МБ. Хранение не у всех конечно. и не у определенного числа пользователей — данные не просто режутся на дольки а создается большое число частей — с избыточностью. скажем, при избыточности 3х у нас получается 30 долек — из которых любых 10 достаточно для получения точной копии. 20 нод из 30 могут уйти оффлайн. избыточность и количество частей можно подобрать. Гарантии оно не дает конечно но вероятность ухода оффлайн всех нод одновременно если N большое достаточно мала.
Достаточно просто решается введением времени жизни на уровне протокола. Сразу обещаем что оффлайн живет неделю скажем. Это все-таки IM.
P.S. существуют распределенные децентрализованные системы, хранящие так информацию (см maidsafe, storj.io)
Никто не говорит что это просто. Это возможно.
Randl
Предлагаю вам отписаться тут.
AllexIn
Волшебство?
Ну а в целом, вы требуете от инструмента то, чего в нем никогда не было и не будет. А именно — гарантий.
IM никогда не был способом гарантированно доставить сообщение. Даже в онлайне. И не смотря на то, что надежность их весьма высока: гарантии — это не про них.
Randl
Доставить оффлайн сообщение с той же вероятностью, что и онлайн.
Daytar
Собственно qTox сейчас именно так и делает.
serf
qTox уже наверно год не может починить багу с потерей соединения после спящего режима, что делает его непригодным к использованию. И при этом насколько я знаю это лучший кросс платформенный криент.
Daytar
Если я верно понял, то это баг не самого qTox'а, а core-либы — https://github.com/irungentoo/toxcore/issues/1550
serf
эта бага уже пересоздавалась раз 5 в qtox, что-то там они решили, но никто так пока и не взялся чинить, то есть как я понял дело не в core
GamePad64
Blockchain, например. Только такие оффлайн-сообщения не получится хранить вечно, будут отпадать по таймауту. Вроде у Bitmessage есть подобное.
viklequick
Правда при включении вашего клиента обратно — получите пачку копий с разных узлов, но это как раз не проблема. Банально введите сообщению GUID и дропайте повторения.