Децентрализованная сеть

[Prizzrak]

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

Я представляю что такое торренты и как они канал грузят представляю. У меня дома например стоит торрент включить, как на всех остальных компах интернет пропадает. Просто тупо канал перегружен и всё. Но торренты - это обычно закачка больших объемов данных. Тут же данных будет ни так много. Потому что общих данных будет совсем чуть-чуть. А данные ресурса будут скачиваться и раздавать только если пользователь запрашивал этот ресурс. А сколько там весит среднестатестический сайт? Не считая картинок ну может быть сотня мегабайт. И это если система какая-нибудь накрученная. Так что думаю такой ситуации как с торрентами не будет. Хотя принцип "перетекания" контента будет очень похожим.

Он просто сольет свои данные в другое место и сотрет всю прогу вместе с архивом. А если ты попытаешься этому помешать, то ты нарушишь права пользователя. И тебе придется ему платить.

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

Они давно работают. В основном их используют хакеры для обхода файрволов. Пойми, как админ, в локальной сети, я могу запретить любые протоколы и программы, если они:
1: Запрещены корпоративными правилами;
2: Используются для обхода правил:
3: Сажают сеть и/или канал наружу;
4: Привели к заражению компа.

В той или иной степени технологии просверливания дырок в NAT на данный момент использую большинство мессенджеров, торренты и половина иных программ работающих с сетью. Потому что большинство компьютеров на данный момент работают за NAT-ом, но при этом программам необходимо прямое взаимодействие между узлами. А так-то да. Закрыть можно всё. Можно вообще интернет перекрыть, чтобы за пределы сети ничего не вылазило и внутрь не попадало. У меня был проект, когда пара серверов вообще была отключена от сети и жила обособлено, видя только друг друга. А с одном из специально выделенных компов эта пара была соединена каким-то хитроспаянным кабелем, через который можно было только специальные пакеты по специальному протоколу посылать. Но такое положение, скорее исключение и если кто-то из клиентов моей сети вдруг окажется вот в такой сети, то ему проще будет через сотовый к интернету подключиться и пользоваться всеми благами. В любом случае решать проблемы администрирования сетей в отдельно взятых организациях не моя задача. Моя задача дать людям возможность создавать бессерверную сеть имитирующую обычный интернет.

[Лекс Айрин]

Просто тупо канал перегружен и всё.

Ты просто не умеешь его готовить))) канал нужно обязательно ограничивать,

Тут же данных будет ни так много.

Это ты так планируешь... а как тебе картинки размером с футбольное поле?.. Ну или хотя бы 10к на 10к Вдруг люди захотят обмениваться ими?

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

Причин много. Забивает все место на диске, подвешивает канал, конфликт с антивирусом/файрволом, неудобство работы..

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

Это НЕ просверливание дырок в NAT это штатный режим работы с внешней сетью. Просверливание дырок это, например, демилитаризованная зона (dmz) или проброс портов. И данные вещи делаются только админом, а не пользователем. Есть еще туннелирование протоколов, когда данные одного протокола перенаправляются через другой, чтобы обойти запрет(ну или отсутствие реализации) использования.

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

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

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

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

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

То он вылетит с работы или будет оштрафован/наказан.

Моя задача дать людям возможность создавать бессерверную сеть имитирующую обычный интернет.

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

[Снег Север]

https://geti2p.net/ru/

[Prizzrak]

Это ты так планируешь... а как тебе картинки размером с футбольное поле?.. Ну или хотя бы 10к на 10к Вдруг люди захотят обмениваться ими?

Ну и будет этот трафик бегать между узлами, которые этими картинками решили обмениваться. В чём проблема-то?

Причин много. Забивает все место на диске, подвешивает канал, конфликт с антивирусом/файрволом, неудобство работы..

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

Это НЕ просверливание дырок в NAT это штатный режим работы с внешней сетью. Просверливание дырок это, например, демилитаризованная зона (dmz) или проброс портов. И данные вещи делаются только админом, а не пользователем. Есть еще туннелирование протоколов, когда данные одного протокола перенаправляются через другой, чтобы обойти запрет(ну или отсутствие реализации) использования.

Я там выше ссылку кидал на UDP Hole Punching. Это то, что используют многие мессенжеры и моя система будет использовать, если я когда-нибудь её сделаю. Вообще самое сложное в сборе моей сети - это установка первого соединения. У большинства существующих сегодня программ есть сервер, который помимо других функций ещё и занимается налаживанием контекта между клиентами. Именно через сервер клиенты договариваются по какому порту они будут взаимодействовать между собой. После того как они договорились, они штатно устанавливают связь через NAT. В моей сети сервера нет. Возникает вопрос, как клиенты будут договариваться. На самом деле варианта 2.
1. Если в сети есть клиент с белыми адресами, то он выступит в роли сервера, который поможет остальным клиентам договориться. Новый клиент должен будет просто указать адрес этого клиента с белым адресом.
2. Если же в сети нет клиента с белым адресом, тогда новому клиенту необходимо будет указать серый адрес одного из клиентов и после этого программа попытается на ощупь установить соединение с клиентом за NAT. На ощупь, то есть перебирая порты ожидая, что на определенной итерации она попадет на порт, который слушает клиент в той стороны NAT.

Первый вариант вообще не отличается от того, что мы сейчас имеем в каких нибудь Skype или Jabber. Второй вариант сопряжен с некоторыми трудностями и придётся над ними поработать. Первый вариант вполне легален. Второй возможно в некоторых сетях может быть воспринят не очень хорошо. Потому что мало кому понравится, что кто-то сканирует порты. Но можно например попробовать договориться, что клиент всегда ждет соединения в каком-нибудь небольшом диапазоне портов. Тогда сканировать долго не придется. В прочем это предложение без глубокого изучения технологии NAT. Может так и не получится.

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

То он вылетит с работы или будет оштрафован/наказан.

На предприятиях где нельзя через сотовый выйти в интерне, а через сеть всё закрыто вряд ли кто-то будет пользоваться этой сетью. Так же как там не пользуются Торентами и различными мессенжерами. Вы меня в чём убедить хотите?

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

А мне кажется ни так уж и тяжело.

[serbod]

А абстрактные денные с помощью этого протокола передавать можно? Хотелось бы на уровне протокола абстрагироваться от данных. Чтобы я делал запрос в которо указывал, что я хочу получить и получал это. Указал, что хочу получить файл, получил файл, данные из БД, получил данные. Захотел конфиг, получил конфиг. И всё это с подписью владельца, чтобы быть уверенным, что не подделка пришла.

Можно передавать любые данные, при этом в каждом пакете есть отдельное поле для метаданных (заголовков, параметров, итд.) и отдельное поле для двоичных данных. В сети есть различные "сервисы", аналогичные портам UDP/TCP. Можно сделать сервис HTTP, который будет отдавать файлы по протоколу HTTP. Или любой другой действующий протокол. Но в логике сервисов есть отличие - на них можно подписаться и они сами будут слать обновления.

Защиту от подделок я не предусматривал, потому что тогда я в этом не разбирался. Сейчас разбираюсь, это часть моей работы. Можно предусмотреть классическую электронную подпись одним ключом и проверку другим. Плюс сделать сквозное шифрование приватных данных на стороне пользователя. Но если пользователь потеряет свой ключ, то потеряет все. Может быть стОит делать "карман ключей", который можно целиком или частично восстановить по разным каналам, а не один общий ключ.

[Prizzrak]

А абстрактные денные с помощью этого протокола передавать можно? Хотелось бы на уровне протокола абстрагироваться от данных. Чтобы я делал запрос в которо указывал, что я хочу получить и получал это. Указал, что хочу получить файл, получил файл, данные из БД, получил данные. Захотел конфиг, получил конфиг. И всё это с подписью владельца, чтобы быть уверенным, что не подделка пришла.

Можно передавать любые данные, при этом в каждом пакете есть отдельное поле для метаданных (заголовков, параметров, итд.) и отдельное поле для двоичных данных. В сети есть различные "сервисы", аналогичные портам UDP/TCP. Можно сделать сервис HTTP, который будет отдавать файлы по протоколу HTTP. Или любой другой действующий протокол. Но в логике сервисов есть отличие - на них можно подписаться и они сами будут слать обновления.

Защиту от подделок я не предусматривал, потому что тогда я в этом не разбирался. Сейчас разбираюсь, это часть моей работы. Можно предусмотреть классическую электронную подпись одним ключом и проверку другим. Плюс сделать сквозное шифрование приватных данных на стороне пользователя. Но если пользователь потеряет свой ключ, то потеряет все. Может быть стОит делать "карман ключей", который можно целиком или частично восстановить по разным каналам, а не один общий ключ.

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

Добавлено спустя 8 минут 21 секунду:
Пока тут с Вами, друзья, общался, придумал как первое соединение устанавливать без всяких там сканирований портов. Можно простую почту использовать. В автоматическом или ручном режиме. В программе формируется сообщение запрос. Потом этот запрос посылается через почту на компьютер где один из узлов системы. Человек на компе получает запрос, копирует его в программу. Та формирует ответ. Ответ отсылается обратно по почте. Получатель копирует себе в программу ответ и два узла знают, как им друг с другом общаться. Ну это опять-таки в теории. Надо будет пробовать.

[Лекс Айрин]

В чём проблема-то?

Вообще-то они не из легких.

Я там выше ссылку кидал на UDP Hole Punching.

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

. Это то, что используют многие мессенжеры

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

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

И не пытайся так делать никогда. За это бьют больно и сажают надолго (с).
Во первых, не найдешь, так как в нормальной сети просто нет свободных незанятых портов. Во-вторых, сниффинг портов это повод записать программу в зловреды. Да и вообще поинтересоваться накуа это надо делать.

Программа если она ждет соединения, открывает один четко известный ей порт, который она сообщает роутеру/серверу и слушает только его, который (порт), кстати, может не совпадать снаружи и изнутри. Это и есть проброс порта. Те, при появлении на нем пакетов, перебрасывают их на нужный комп.
Ну и контролирует соединение она сама. И именно этот механизм используют (должны) все менеджеры и прочие программы. Фактически, получается три белых адреса: сервер соединений, роутер А и роутер В. После соединения сервер-посредник уже не нужен.

На предприятиях где нельзя через сотовый выйти в интерне, а через сеть всё закрыто вряд ли кто-то будет пользоваться этой сетью.

Тогда все нормально. Просто уже были прецеденты с подобного рода технологиями.

А мне кажется ни так уж и тяжело.

Пробуй))) Посмотрим.

[olegy123]

То есть спросил у системы файл и она выплюнула тебе файл. Спросил у системы строку базы данных и она выплюнула строку.

как собираться будет информация?
Как ноды будут синхронизироваться.

Добавлено спустя 8 минут 49 секунд:
в свое время, мне предложили заняться разработкой торрент-тв.
Подумав, оценив все я сильно засомневался в эффективности данной затеи, предложил иной вариант решения. Которая позволяет при текущих подключениях иметь неограниченную по количеству каналам пропускную способность. Вообще никак не зависящая от кол-ва потребителей.

[Prizzrak]

как собираться будет информация?
Как ноды будут синхронизироваться.

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

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

Тут вариант иного решения не пойдет. Потому что задача сделать сеть без серверов.

[Лекс Айрин]

Потому что задача сделать сеть без серверов.

Это невозможно. Даже в офисной как бы бессерверной сети один из компов все же является сервером. Скорее речь может идти о минимизации нагрузки на сервера.

[serbod]

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

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

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

[Prizzrak]

Потому что задача сделать сеть без серверов.

Это невозможно. Даже в офисной как бы бессерверной сети один из компов все же является сервером. Скорее речь может идти о минимизации нагрузки на сервера.

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

Добавлено спустя 1 минуту 32 секунды:

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

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

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

Ну да. Как-то так. Ещё я планирую добавить подпись. Чтобы быть уверенным что присланные куски ресурса принадлежат тому, кто этот ресурс опубликовал и не было подмены.

[Лекс Айрин]

Почему невозможно? Все узлы сети являются источником данных для ресурсов (для строк БД, файлов скриптов, конфигов). Но сам сайт собирается из файлов и данных уже на машине того, кто ресурс запросил.

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

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

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

[Alex2013]

Если я верно понял "Децентрализованная сеть" будет напоминать мешь сеть Гиперборею ... и мой проект Web2

Это и среда распределенного обмена данными и общения (Что-то вроде реинкарнации сети ФИДО причем к нодам можно будет обратится как со спец-софта расширяющего возможности и сохранность локальных архивов так и с помощь обычного браузера ... )
...и проекты для дистанционного обучения ...
...и разумеется весь спектр приложений которые неплохо бы Вебо-фицировать ...
+ само собой разные онлайн игры и просто простые сайты-визитки не нуждающиеся в размещении на платном хосте ...

Так что могу немного посодействовать ...
(Готовых решений у меня пока нет, но как минимум я кое что обдумал и попробовал реализовать )

Из самописного софта уже есть сервер со скриптами ...


Настраиваемый и расширяемый "редактор форм и страниц" (правда пока довольно примитивный )


И вот такой гибрид сервера и браузера...

Зы
В принципе все, что ты озвучил решается в рамках веб-приложения и простого сервера (а также возможно специального браузера заточенного под конкретные задачи ) Децентрализация в доступна в любом количестве и качестве + есть возможно использовать огромное количество открытых онлайн-сервисов для расширения функциональности . (Шифрование тоже доступно причем нестандартное со сжатием данных . ) Единственное узкое место надежность защищенность сервера ( или сети серверов) но можно просто сделать белый список или использовать онлайн "сервис посредник" (причем ЛЮБОЙ от "шары" до "почты" или "лички" любого форума ... главное "заметать следы" то есть удалять пакет после завершения транзакции ) для передачи данных через глобальную сеть
И разумеется нет никакой разницы использования технологии веб-приложения в локальной и глобальной сети .

[Balans]

Анонимность я как раз не прорабатываю на данный момент. Приватность - да, анонимность - нет.

Если задача обеспечения анонимности не ставится, то ZeroNet. Однако могу добавить, что новая p2p-сеть любого назначения, не преследующая цель обеспечить анонимность коммуникаций, обречена.