bjsonrpc is a implementation of the well-known JSON-RPC protocol over TCP-IP with lots of features. It is aimed at speed and simplicity and it adds some other extensions to JSON-RPC that makes bjsonrpc a very powerful tool as a IPC mechanism over low bandwith.
Imagine two computers connected through a network. It could be a reasonably fast network (10mbps LAN), a probably faulty network (3mbps WiFi), or maybe a very slow connection (1000/300kbps Internet connection). And we want to be able to communicate and interact between two programs one on each party.
Which one is the server (has the listening port) and which one is the client (will try to connect the other one) is a decision that matters for most installations.
For example, a portable device that connects through a Wireless network is better to configure it as a client, and a server should be something more reliable (a machine with a cable connection, which is running the most of the time).
But most of the client-server protocol schemes will force you to put the server to one specific device, and the client in the other. To be more specific, in RPC-like protocols, the server usually must be the one that recieves calls, and the client is the one that sends them. This limitation that seems logic, isn’t enough on most professional RPC systems, there are lots of RPC uses that require a “reversed configuration”, and some other uses require the both things at the same time.
bjsonrpc is designed from scratch with some of this ideas in mind to overcome this limitations (there are several others i’ll explain later). It uses the JSON-RPC protocol over TCP/IP sockets (does not handle nor creates HTTP connections), and should be fairly compatible with other JSON (1.0, 1.1) clients and servers. In bjsonrpc there are two basic rules that aren’t in the basic JSON protocol specification:
The messages sent are simple JSON objects followed by a newline ‘\n’ separator. You should keep messages as short as you can. That will give you better response speed with slow connections. If you plan to send lots of data through a message consider dividing them in small parts (about 4K of data per message). Peers could hangup waiting for receiving one big-packet and leaving the rest for later.
bjsonrpc implementation aims to: