— Pixels Commander

[ In English, На русском ]

А нужен ли нам сервер? P2P распространение Web приложений

Изоморфизм — возможность исполнения одной и той же базы кода на сервере и клиенте. Своим появлением он обязан возможности исполнять серверный JS с помощью Node.js, а по настоящему популярным стал благодаря распространению React. На данный момент изоморфизм — один из самых горячих и востребованных трендов Web разработки и это лучшее время что бы оценить последствия его появления, рассмотреть изоморфизм как ступень к совершенно новым архитектурам и решениям. В этой статье рассматривается одно из них — виральный Javascript применяемый для P2P распространения Web приложений.

Благодаря текущей востребованности изоморфизм оброс инструментами. Самыми популярными из них является Web сервер Express используемый для доставки приложений клиенту и UI библиотека React позволяющая рендерить компоненты как в DOM в браузере, так и в строковый HTML на сервере. И если использование Express является практически безальтернативным, то клиентских библиотек поддерживающих изоморфизм существует достаточно большое количество, однако вне зависимости от того какую из них вы выбираете основная концепция изоморфного кода не меняется. Главным достижением изомофрного JavaScript стала унификация кода в браузере и на сервере которая практически размыла грань между ними. Теперь основным различием клиента и сервера становится не специфичность кода, а возможность сервера раздавать контент. Но что если пойти дальше изоморфизма и предположить, что возможна передача приложений с клиента на клиент? Что если мы можем полностью уничтожить разницу в функциональности серверного и клиентского кода? Таким образом каждый клиент получивший код приложения становился бы его распространителем или носителем если провести аналогию с распространением микроорганизмов в природе, а самой технике неплохо подходит название виральный JavaScript (Viral Java Script).

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

Рис.1 — Традиционное распространение приложения. Сервер отдает пакет множество раз, интернет каналы предприятий загруженны пропорционально.

Рис.2 — При P2P распространении приложение попадает в корпоративную сеть предприятия и далее передается от компьютера к компьютеру по внутренним каналам связи. Это уменьшает загрузку сервера и использование интернет — канала предприятия.

Или единожды попав из США в Европу приложение будет распространяться внутри европейских провайдеров не совершая трансконтинентальных путешествий.

Рис.3 — При обычном способе распространения пакету приходится изрядно попутешествовать, если клиент находится на другом континенте.

Рис.4 — P2P модель распространения позволяет избежать множественной трансконтинентальной передачи приложения.

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

Как работает виральный Java Script?

ViralJS algorithm scheme

  • При запросе от нового клиента сервер определяет есть ли рядом с запрашивающим доступные пиры (носители)
  • Если подходящих носителей нет — то приложение отдается полностью с сервера, а в конец приложения дописывается виральный скрипт (Viral Addition). Viral addition исполняется на клиенте после получения приложения и отправляет на сервер информацию о том что текущий браузер стал носителем приложения. Сервер добавляет его в список доступных пиров. Так же Viral Addition отвечает за обработку P2P запросов от новых клиентов;
  • Если же сервер находит подходящего носителя рядом с клиентом, то отдает не все приложение, а лишь минимизированый скрипт (Thin Client) с инструкцией «запросить приложение у носителя Х и развернуть локально»;
  • Сервер передает носителю P2P координаты клиента, а клиенту координаты носителя, благодаря чему они устанавливают прямое соединение и клиент получает приложение с носителя;
  • Клиент разворачивает скрипты приложения, тем самым завершая запуск и становясь еще одним носителем.

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

ViralJS — готовая к использованию имплементация вирального контейнера. Для того что бы начать распространять ваше приложение через P2P достаточно подключить ViralJS в проект и добавить его, как middleware к вашему ExpressJS приложению:

var ViralContainer = require('ViralJS');
var viralContainer = new ViralContainer();
app.use(viralContainer.middleware);

Так же ViralJS имеет API для передачи сообщений между участниками системы и подписи передаваемого от носителя к получателю контента. Для того что бы передать объект получателю достаточно в коде сообщения вызвать

ViralContainer.writeMeta(someObject);

, а на носители обратиться к этим данным через

ViralContainer.meta

Заключение

Как видите сделать ваше приложение виральным достаточно просто. На сегодня передача P2P сообщений между браузерами (технология WebRTC) поддерживается Firefox и Chrome, а Microsoft и Apple обещают внедрить API в ближайшем будущем. Даже сейчас имеется фоллбек который не ухудшает качество приложения относительно исходного — пользователи Safari и IE/Edge получат от сервера обычное Web приложение и проблема кроссбраузерности по факту отсутствует.
Как уже говорилось выше — P2P Web интересен с точки зрения уменьшения издержек на серверную инфраструктуру, оптимизации пути проходимого приложением, но больше всего вдохновляет для экспериметов и которые открывает виральный JS и перспектива следующего шага, но не смотря на это ответ на вопрос из заголовка будет «Да, нам все еще нужен сервер для первоначальной раздачи и координации P2P сети.»

  • https://perguth.de Аноним

    Maybe beyond the horizon of distributed distribution in the browser is something like distributed general computing in the browser. «EtheriumJS» maybe?!

  • Аноним

    Remote web worker may be good indeed.

  • http://broadinstitute.org/~slowikow Kamil Slowikowski

    QMachine by Wilkinson and Almeida, 2014

    «Modern web browsers can now be used as high-performance workstations»

    http://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-15-176
    https://github.com/qmachine/qmachine

  • Marco Oliveira

    Does Viral.js handle file tampering in any way? I’m wondering what happens if I create a malicious node that starts serving a very similar website with some additions, like loggers to obtain user data, etc. Is there any check of the authenticity of the files being served?

  • Gregory Magarshak

    Try implementing SRI — subresource integrity. This is the standard mechanism by which browsers handle tampering. The tricky bit is where to publish the hashes officially. Ideally it would be stored in a blockhain eg a hash of a merkle tree on a bitcoin blockchain.

  • Аноним

    Thanks for hint. There is still a server to signal between seeds so we can keep hash there.

  • Edoardo Causarano

    Just hash the files and use it as the URL

  • Dylan

    Very interesting idea! I think it would go well with https://github.com/rill-js/rill (an isomorphic framework that basically brings express to the browser). Is there any plans to support other frameworks with this such as koa, hapi etc?

  • Аноним

    True, looks like a matching idea.