ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arzhan Kinzhalin <arz...@kinzhal.in>
Subject App Container/Ripple UI split: browser-to-browser P2P RPC and eventing
Date Thu, 21 May 2015 19:15:46 GMT
Hi;

so I was thinking along the lines of separating the application "container"
and from the Ripple UI/controls so that the erroneous application behavior
would not impact user experience of using the emulator.

One of the pieces that surely was missing was ability to make calls from
one client runtime (browser) to another. Right now all the pieces reside in
the same runtime which one one hand makes the calls easy, but, on the other
makes the emulator vulnerable to the glitches in the app being emulated.

So, I went ahead and implemented a simple P2P mechanism based on WebSockets
and brokered by a WS-based proxy. The prototype is available here:
https://github.com/busykai/ws-rpc . See README.md and the code for more
details. I've evaluated a couple of alternative (most notably, stuff based
on WebRTC), but it seems to be an overkill for the very specific purpose we
need a P2P mechanism, plus they lack ability to call and eventing. What I'm
proposing, is a very lightweight code, specifically tailored for Ripple, to
accomplish the same goal.

Basically, if we have browser1 and browser2, the following happens:

1. browser1 and browser2 must learn an id of the "channel" and the location
of the proxy server. currently the channel id is hard-coded (should be
injected or returned separately) and proxy port passed as the query string.

2. browser1 connects to the proxy (broker).

3. browser2 connects to the proxy.

4. once there are two peers on the same channel id, a tunnel gets greated.
the peers are notified they are connected.

5. browser1 publishes the api (in a declarative fashion, as a JSON
description).

6. browser2 recieves the publication and generates a global "peer" object
with the function stubs. the signature of these functions is exactly the
same + callback is added as the last argument. this callback is used to
return result. all the calls, thus, become asynchornous.

7. browser2 calls browser1's published API as a function, providing a
callback to get the result.

If you clone/download the repository, it provides a simple example of two
browsers publishing identical API which can be ran using 'node main.js'. It
will start the broker and launch one browser. Copy the URL and paste into
some other browser. Once both browsers are connected, you can press "Peer
User Agent" button which calls the 'userAgent()' function on the other side
and prints the result.

The events are not yet implemented, but since the connection between the
browsers is persistent and duplex, publishing and subscribing to the events
is almost the same thing as publishing and calling remote functions.

My next steps are to modularize the code of the prototype a little bit
(it's now intermixed with the example code) and create a branch of Ripple
that implements the UI/container separation idea on top of this mechanism
(which will be improved a lot in the process). This way will have code in
open source to start with.

Please let me know if you have any comments, feedback on the mechanism. It
will be greatly appreciated!

Thanks,
Arzhan

-- 
// kai

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message