— Pixels Commander

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

Do we still need a server? P2P distribution for Web applications

Isomorphism – is an ability to run the same code and generate UI on server side as well as on client. It owes it`s appearance to the power of Node to run server side Javascript and became really popular in recent years after ReactJS established. Isomorphism is one of the hottest and on demand topics in Web development at the moment. This is right time to assess it`s value and effect and to review isomorphism as a one more leap towards new kinds of architectures and solutions. This article is a dive into one of them – viral Javascript technique which is used for Web applications P2P delivery.

Because of current demand isomorphism got awesome and powerful tooling. Most popular isomorphic toolset is Express server framework which delivers apps to client and React UI library which allows to render components to DOM for being executed in browser as well as to HTML string for being executed on NodeJS server. And if Express barely have any alternatives there are a lot of competing isomorphic UI libraries. However does not matter which one you use the essential of isomorphism remains the same and the most significant achievement here is an unification of codebases between server and browser. The boundaries between them are blurred by isomorphism and the only difference now is not a codebase specifity but server`s ability to deliver application to clients. And what if we go further supposing that client can deliver application to others? What if we can erase the boundaries between server and client completely? In this case every client which got application`s code becomes it`s distributor or carrier. And drawing the analogy with spreading microorganisms in the nature this technique perfectly matches “viral Javascript“ naming.

P2P content distribution allows to reduce server load which is going to be interesting for social and non-profit organizations and projects, also this may decrease network latency since peering could be set up in the way content to be delivered from the nearest peer available. For example after hitting corporative network application will be delivered inside of it using high speed internal channels without creating a load on company`s internet channel.


Pic.1 – Traditional app distribution. Server sends package many times, corporative internet channels are loaded appropriately.

Pic.2 – In case of P2P distribution application hits corporative network once and then is distributed using high speed internal network. This reduces server load and corporative internet channel load.

Or another case – once application got from USA to Europe it is delivered inside of European networks only without creating transatlantic traffic.

Pic.3 – It takes a lot of transatlantic trips to transmit an app when doing it in a traditional way.

Pic.4 – P2P allows to reduce number of transcontinental transfers and reduce server load.

By distributing application via P2P you create a self-establishing and self-evolving CDN which moves data closer to client.

How does viral Javscript work?

ViralJS algorithm scheme

- When server receive a request for an app it determines are there any peers available nearby the requester.

- If there are no matching peers client receives full application code from server and small viral script (viral addition) is added to the end of application code. Viral addition executed on client after app transferred completely. It connects to server and notify server about one more peer available. Also viral addition is responsible for serving P2P requests from other clients, basically this is a code which send application to next peer;

- If server finds a correct peer it respond with a minimalistic script (thin client) which contains instruction to connect with peer X`s viral addition, receive application from there and deploy it locally;

- Server helps seeding peer and receiving peer to exchange P2P addresses;

- They establish direct connection and carrier sends application to the recipient;

- Recipient executes code it received which launches application and makes him one more active peer.

Algorithm is simple enough but requires pretty a lot of code to run and some details to be taken into account: How to send static files? How to cache content? How to render app on carrier? How to exchange P2P adresses? Easy answer to all of them can be ViralJS.

ViralJS is a ready to use viral container implementation. To start distributing your app through P2P it is enough to include ViralJS into your project and use it as Express middleware:

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

Also ViralJS have an API for messaging from carrier to recipient and signage of transmitting content. So for sending object to recipient you may call

ViralContainer.writeMeta(someObject);

, and recipient may read this data via

ViralContainer.meta

Conclusion

As you see it is a few lines of code to convert your app into P2P distributable one. As on today P2P messaging between browsers (WebRTC technology) is supported by Firefox and Chrome. Microsoft and Apple gave a promise to add WebRTC support to their browsers by the end of 2015. Even now there is a fallback which does not reduce quality of delivered app –  Safari and IE/Edge will just receive regular application without viral addition which means that there is no compatibility problem when start using P2P distribution. As we said before – P2P Web is interesting from infrastructure cost and latency reducing perspective, but also viral Javascript it is an inspiring foundation for next quality leaps for brand new, experimental Web architectures and solutions. However even it is amazing opportunity to move forward the answer to the question from title is: “Yes, we still need a server to make initial distribution and signaling between peers.”

  • https://perguth.de Anonymous

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

  • Anonymous

    Remote web worker may be good indeed.

  • 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?

  • 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

  • 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.

  • 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?

  • Anonymous

    True, looks like a matching idea.

  • Anonymous

    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