Как правильно органозовать p2p чат?

Почитай про DHT.

На данный момент больше всего интересует как можно узнать адрес хотя бы одного клиента находящегося в сети.

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

На данный момент больше всего интересует как можно узнать адрес хотя бы одного клиента находящегося в сети.

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

И не привязывай пользователя к ноде, объектами в твоём чатике должны быть чаты, сообщения, файлы и пользователи, а ноды должны использоваться только для хранения и обмена.

Чатик не на ресте делается, а на вебсокете. И тот броадкастами засрать легко. Подключи любой торрент по DHT и посчитай время когда придется первый сид. Вот столько же будет идти твое сообщение в большинстве случаев.

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

Это то понятно, рест я упомянул как пример работы со сторонними сервисами, а не для связи между клиентами.

Спасибо за наводку, буду изучать.

вот поэтому привязывай к явно работающей DHT-сети того же торрента а не городи новую.

привязывай к явно работающей DHT-сети того же торрента

А это совсем неплохой ход: чат в виде спутника торрент-клиента, у которого уже имеются подключения.

не обязательно.
просто DHT торрент, как гигантсткую активно работающую и потому хорошо связанную сеть, использовать как систему поиска клиентов.

А вот что, если в сети нет ни одного клиента и при подключении к сети все предустановленные адреса в офлайн?

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

Подключи любой торрент по DHT и посчитай время когда придется первый сид. Вот столько же будет идти твое сообщение в большинстве случаев.

Когда увлекался Tox то сообщения там проходили нормально, за секунду две.

И потом, даже в торренте время поиска ПЕРВОГО имеющего этот торрент пира и соответственно начала закачки сильно зависит от присутствия в DHT сети и если уже активно несколько закачек то торрент и пир могут находится очень быстро.

В общем не недооценивай пиринговые сети.

просто DHT торрент, как гигантсткую активно работающую и потому хорошо связанную сеть, использовать как систему поиска клиентов.

Может тогда не мучится и просто выделить DHT из торрента в самостоятельный сервис?

Такой сервис придется поддерживать. Поэтому как мне кажется будет практичнее использовать существующие. Но где мне найти список открытых нод? Попробовал подключится к «router.utorrent.com», «dht.transmissionbt.com», «dht.aelitis.com» и еще несколько, но безуспешно.

Но где мне найти список открытых нод?

Посмотри в исходниках клиента где они хранятся, причём скорее всего они прямо в них и указаны.

Вообще списки инициализирующих пиров обычно состоят не из доменов, а из IP.

Такой сервис придется поддерживать. Поэтому как мне кажется будет практичнее использовать существующие.

Запомни жизненную мудрость6 аморальные решения обычно ли вредны или вообще смертельно опасны.
Так же и тут, даже если ты прицепишься к имеющийся сети и будешь в ней сождавать повышенную нагрузку поиском нод своей подсети то ты не только у себя будешь делать больше вычислений и себе же делать больше трафика и привлекать к себе не нужное внимание, потому что паттерн опросил порт и отключился выглядит как поиск уязвимого компьютера, так ты должен будешь всё равно писать код который всё это будет делать.

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

Ясно, спасибо большое за помощь!

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

Ясно, спасибо большое за помощь!

На мой взгляд DHT надо сделать так:
DHT на каждой ноде запускается как отдельный сервис, к которому множество клиентов обращаются через библиотеку, которая ничего кроме запросв к серверу и получения ответов не делает.
Возможно стоит чтобы запросы в сервер шли по ip/ipv6 чтобы ты на одну свою подсеть мог держать только один DHT сервер ip которого будешь указывать в параметрах запуска программы.
По умолчанию этот адрес будет 127.0.0.1

Сами же запросы будут делаться так: клиент регистрирует на DH сервере свой ip/ipv6 адресс и номер порта по которому ждёт коннект, тестовую строку переменной длинны со своим ID, тестовую строку переменной длинны с идентификатором используемого протокола или названием программы, а так же переменную с используемой кодировкой(utf8 по умолчанию) и типом содержащихся данных(целое число, текстовая строка, закодированное бинарное значение в base16, base32, base64 и т.д.

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

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

Не совсем понимаю преимущество ipv6 в данном случае.

ipv6 это будущий стандарт интернета, ты же ведь не хочешь спешно под него переписывать весь функционал когда оборудование под него просто перестанут выпускать?

К стати я тут подумал о том, что на DHT сервер и клиентскую библиотеку надо бы ещё и пробитие NAT повесить.

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

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

Явных сроков перехода вроде не намечали на сколько мне известно. Да и я не думаю что ipv4 просто возьмут и отрубят.

Ну лучше быть готовым и заложить в архитектуру необходимые структуры с заглушками, чтобы потом просто дописать нужный код, а не перекраивать всё заново.

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

не получится.
эффективность ДХТ прямо пропорционально количеству пользователей. если в сети полтора землекопа, то ее эффективность на уровне плинтуса.
торрент обеспечивает кучу пользователей

можно закостылить и запрашивать пиров lts сборок убунты или дебиана с их серверов. хеши и адреса серверов есть в торрентах на оф.сайте.
немалая часть полученных пиров будет поддерживать DHT, ну а дальше все в твоих руках месенджера.

Целесообразно использовать уже готовый раствор: Этот Session Messenger (от Loki Foundation) является ответвлением Signal Messenger (который официальные лица ЕС используют в качестве безопасного устройства).

Мы используем его без номера телефона, просто установив сеанс: «Создать учетную запись»> «Идентификатор сеанса» устанавливается (то есть номер сеанса)> вы можете получить этот номер в виде QR-кода. Вы можете отправить этот номер своим друзьям (например, по электронной почте), чтобы они установили его в их сеансе, и когда они это сделают, у вас будет безопасное соединение. Это блокчейн-устройство. Итак, у нас есть инструмент, который технологически опережает репрессивные режимы.

https://getsession.org/faq/

Так это пока, а потом по мере того, как всё больше программ начнёт использовать этот сервер DHT для поиска своих пиров эта проблема сама по себе исчезнет.

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

Первый способ подходит для локальных сетей. Клиенты периодически посылают broadcast, все его видят и запоминают, что по такому-то адресу сидит клиент. Второй способ подходит для любых сетей, но требует ручной работы: изначально пользователь добавляет адреса одного или нескольких известных узлов. После этого клиент связывается с этими узлами и узнает от них адреса других клиентов и так далее. Третий способ - просто пытаться связаться со всеми IP-адресами в мире, где-нибудь, да найдётся. Тут нужен фиксированный порт и этот способ не сработает для IPv6, поэтому его применять особого смысла нет.

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

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

Представь, что ты вошел в Олимпийский, где помимо тебя присутствует еще несколько тысяч человек. И тебе надо найти среди них одного конкретного человека, и после этого обмениваться с ним сообщениями в этих условиях.

Вот ровно то, что ты будешь предпринимать, чтобы это сделать - и есть способы реализации p2p.

Что понимается под «одноранговой» сетью и под «клиентом, находящися в сети»?

Если речь про локальную сеть, то можно использовать avahi.

https://github.com/TokTok/c-toxcore - это ядро бессерверного мессенджера tox. Там есть и документация и исходный код.

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

Хотелось бы реализовать что то свое, если честно(велосипед?). Делать еще один токс на его ядре нет ни скилов ни желания, если честно.

Если под это определение попадает использование серверов, но без непосредственной передачи сообщений через них, то можно воспользоваться любым STUN-сервером для получения информации об IP и портах, а (например) discovery.etcd.io для (временной) привязки этой информации к идентификатору чата. После этого клиенты могут общаться напрямую через UDP.

# Клиенты узнают свои внешние IP:udpport с помощью STUN, см. RFC5389.

PREFIX=$(curl https://discovery.etcd.io/new)

# Клиенты некоторым образом обмениваются значением $PREFIX

curl $PREFIX/client1 -d value=198.51.100.16:12345 -X PUT
curl $PREFIX/client2 -d value=203.0.113.222:54321 -X PUT

# Клиенты узнают IP:port друг друга

curl "$PREFIX?recursive=true"

После чего начинают посылать друг-другу сообщения, или keep-alive, если нечего слать в течении 55 секунд (обычно NAT держит запись в таблице около двух минут, так что этого должно хватить).

Если keep-alive перестали доходить, то снова идём в $PREFIX и проверяем, не обновил ли сосед IP:port.

Когда в такой системе будет достаточно участников, то можно будет выкинуть бутстрапный discovery.etcd.io и хардкодить в клиента список самых «живучих» узлов, с которых можно получить IP:port всех остальных.