Real-time bi-directional JSON-RPC communication over HTTP
Asked Answered
P

4

11

I am building a JSON-RPC server that accepts requests over HTTP. I would like to support bi-directional communication (both client and server can send requests), the specific use case being a publish/subscribe architecture where a client sends a subscribe(X) request and receives changed(X) requests in (almost) real-time. As far as I know, there are several ways to implement this with HTTP:

  • long polling
  • WebSockets
  • polling calls using a cookie-based session model
  • streaming (keeping the HTTP connection open)
  • a combination of some of the above

What I'm looking for is a solution that is based on accepted internet standards (if possible), usable from a web browser and easy to work with on the client side. So far, I favour the streaming thing (Twitter, CouchDB do it that way), but I'm not sure about how well this is supported within browsers and JSON-RPC libraries. Also, there may be other ways to do it that I'm not aware of.

Thank you in advance.

Padua answered 27/1, 2011 at 23:28 Comment(0)
E
3

I think you should have a look at socket.io to accomplish your task. You could if you wanted to watch this video from the author: "Socket.IO Workshop: Guillermo Rauch". It is easy to work with on both server as client. I have created a simple sample pubsub using redis on top of socket.io.

Elbertine answered 28/1, 2011 at 16:20 Comment(1)
thanks for the link to socket.io. my HTTP server component already exists (in Erlang) but socket.io's approach is hugely inspiring.Padua
S
3

To my knowledge, Streaming is supported by FF, Chrome (Has bufffering issues that require a datatype of application/octet-stream or a prelude to work) and IE8 (through a little XDomainRequest). I don't know about opera.

I don't really know of any comet industry standards, the Bayeux is probably the closest. It's hard to see how facebook/gmail/twitter do it as all the code is obfuscated, and it's exceedingly difficult to find much info on how all the browsers handle everything.

Even more difficult is that you will need to use a specialized server, keeping this many connections open will require thread pooling etc.. A normal server will blow up pretty fast.

It is a very powerful design if you can get it to work reliably though.

Selfhood answered 28/1, 2011 at 15:53 Comment(1)
Tornado claims that can support thousand of parallel connection and is used at FriendFeed (now Facebook). It's also open-source tornadoweb.org.Huihuie
E
3

I think you should have a look at socket.io to accomplish your task. You could if you wanted to watch this video from the author: "Socket.IO Workshop: Guillermo Rauch". It is easy to work with on both server as client. I have created a simple sample pubsub using redis on top of socket.io.

Elbertine answered 28/1, 2011 at 16:20 Comment(1)
thanks for the link to socket.io. my HTTP server component already exists (in Erlang) but socket.io's approach is hugely inspiring.Padua
C
2

You should take a look at JSONRPC-bidirectional.It supports bidirectional RPC over WebSocket, Worker, WebRTC and HTTP and it is highly extensible.

Carrera answered 16/6, 2019 at 14:47 Comment(0)
P
1

If anyone is interested in a Java implementation I just wrote a sample app and a blog post about it. It uses Java, Maven, Comet, Bayeux, Spring. http://jaye.felipera.cloudbees.net/ http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo

Pisa answered 19/2, 2011 at 13:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.