Ответы пользователя по тегу P2P
  • Почему до сих пор никто не создал p2p мессенджер?

    jamakasi666
    @jamakasi666
    Просто IT'шник.
    Потому что у p2p только один единственный плюс в виде децентрализации и он же является минусом перечеркиващим все остальное. Сам p2p также фигово предназначен для передачи мелких и РАЗНЫХ данных но хорошо для передачи мелкими кусочками болищих неменяющихся данных.

    Т.е. грубо говоря одно дело идет раздача 1гб данных куче пиров которые также становится раздающими и в целом ускоряют раздачу потому что этот гиг хочет 1000 человек. Другое дело у тебя 10 байт текста обвязанных 300 байтами служебки и их надо передать одному единственному или паре пиров, остальным он не нужен, в таком случае сеть грубо говоря превращается в кучу шлюзов ретрансляторов из разряда ПирА(отправляет сообщение пиру Я) -> увидел пирБ(не мое передам дальше и затру у себя)->...-> поймал пирП(не мое передам дальше и затру у себя) ->...->->получил пирЯ(а это мне!). В савокупности для передачи породится космическое число мусора и изначальные байта сообщения по дороге выжрут мегабайты чужого трафика. Кроме того время доставки сообщения может быть очень большим пока сообщение путешевствует от пира к пиру даже потому что иногда придется искать маршрут что говорится в слепую не зная с какой стороны находится адресат.
    Почему на мобилках не интересен и не популярен тот же токс, ну вот ты пользуешься торрентом на телефоне? Аааа трафик жалко стало да? вот и тут схожая ситуация.

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

    Намного более интересные это жаббер\matrix которые могут быть гибридными, проще это представить как почту где ты привязался к сервису например яндекс и можешь отправить сообщение пользователю который привязан к гуглу, каждый сервис имеет свои плюшки а если что то не нравится то всегда можно найти другого провайдера почты. Но к сожалению яббер не нашел массового успеха погрязнув в стандартах изза чего потерял совместимость, а матрица досих пор в каком то непонятном состоянии.
    Ответ написан
  • Способы реализации p2p обмена сообщениями. Каким образом blockchain может быть использован в создании мессенджера?

    jamakasi666
    @jamakasi666
    Просто IT'шник.
    Совсем отказаться от серверов или чего то что будет говорить где какой клиент крайне сложно. Мы живем в мире где куча НАТов и серых ip адресов с динамикой.
    По факту Вам надо решить следующие проблемы:
    1) Реализовать "пробивалку" NATов. Способов много и нужно учитывать максимальное их количество. Это и UPnP, и возможность пробития порта через соседа который это может сделать и соединение с другим клиентом и уже через него выходить в общую сеть обмена.
    2) Нужен некий механизм доверия между клиентами т.к. никакого центрального сервера авторизации не будет. Тут способов тоже много и чаще всего применяется шифрование по некоторому ключу который генерируется у каждого клиента к каждому клиенту, после чего хранится локально. Даже если некий клиент прикинется другим клиентом с его ключем то ничего не выйдет. Сообщения дойдут но прочитать их он уже не сможет без индивидуальных ключей к каждому клиенту которые злоумышленник узнать уже не сможет никак.
    3) Понадобится некая реализация системы для сообщения IP адреса и порта клиентов друг другу. Тут уже варианты абсолютно разные со своими плюсами и минусами. Самый простой это некоторый сервер который только знает ip:port:идентификатор_клиента, с ним все и работают(естественно ничего более этот сервер не делает и сообщения и данные ходят между клиентами напрямую).
    Другой вариант это все тот же сервер который дает и знает ip:port:идентификатор_клиента но отличительно то что он динамический и создается у лучшего клиента(лучший выбирается по неким критериям типа хороший инет, выделенный ip, отсутсвие ната и т.д.). Т.е. сервер все также остался но переехал к самим клиентам и мало того их стало много. Этот способ и есть DHT и из него вырастает следующая проблема.
    4) Т.к. теперь у тебя полностью децентрализованная сеть на основе DHT или своего велосипеда который тоже повторяет DHT выросла проблема в том что клиенты могут оказаться в разных сетях с этими DHT и вообще не знать друг о друге. Тут понадобится реализация некоего механизма что бы DHT сервера искали и знали друг о друге. Как это будет реализованно тоже огромный геморойный вопрос, можно сделать еще один слой в виде DHT над DHT, можно сделать некоторые центральные сервера, можно пойти путем жесткого бродкаста между DHT узлами и т.д.

    Полноценно настоящая децентрализованная сеть возможно только в мире где у каждой железки в сети свой уникальный статичный IP и полностью отсутсвуют фаирволы а сама сеть построена без шлюзов и без деления на подсети. Но как понятно такого никогда не было и не будет но возможно внутри маленькой локальной сети.
    Чуть не забыл, такой p2p чат уже существует в виде Tox. Отдельно существуют подобные чаты в виде плагинов в битторрент клиенте Vuze-.
    Ответ написан
  • Как соединить 2 компа напрямую?

    jamakasi666
    @jamakasi666
    Просто IT'шник.
    Мало информации, лучше нарисовать псевдосхемой.
    Как я понял комп1 где то далеко, прячется за натом провайдера? Или от провайдера ip статичный и белый а серый нат только на стороне локалки в виде обычного роутера?
    Комп2 я так понимаю ваш комп.
    Вопрос где находится сервер? у вас, вместе к комп1 или где то отдельно и имеет свой статичный внешний ip?

    Если комп подходит под описание того что нат у него внутри своей локалки то надо просто пробросить dmz зону на комп1. Если доступа к роутеру нет но есть upnp то шаманить и програмно пробивать себе порт через upnp.

    Другой вариант это любой vpn.

    Еще 1 вариант это написать простейший аналог turn сервера. Т.е. грубо говоря где то на сервере у которого есть возможность открывать любые порты и присутсвует белый внешний ip стоит turn сервер. Turn в самой простой реализации будет работать так:
    По дефолту ждет соединение на любом порту, пусть это будет даже сокетное соединение. При получение входящего соединения начинает ждать 2е соединение. После подключения обоих клиентов он у каждого получает input и output концы, затем кросирует их между собой. комп1(output)->комп2(input) и наоборот комп1(input)->комп2(output). В конечном счете сервер просто проксирует соединение, для комп1 и комп2 соединение будет именно друг с другом но в тоже время сами они будут являться клиентами для turn сервера, нат становится не проблемой, серый ип тоже.
    Ответ написан