vphantom / js-jrpc Goto Github PK

We are sourceing pages in the browser using https. For that reason we need to use secure ws (wss). Our embedded devices are on a LAN (192.168.0.* ip addresses).

When the browser tries to connect a wss to the embedded device, we get the error net::ERR_CERT_AUTHORITY_INVALID

We are having trouble working out how to generate the embedded side certification which allows the browser to connect using wss.

Is there a simple standard way to do this ?
Currently we have been trying to self sign certificates... however we aren't having much luck.

Hi,

I created a helloworld:

const rpc = new JRPC({remoteTimeout:10});

rpc.expose("foo", function(params, next) {
    console.log("fooo called")
  return next(false);
});

rpc.call("foo", {},function(err, result) {
    if (err) {
        console.log(err)
      // Something went wrong...
    } else {
        console.log('success')
      // 'result' was returned by the other end's exposed 'foo()'
    }
  }
  );

And I always got { code: -1000, message: 'Timed out waiting for response' }.
Am I missing something?

Thanks,

Hi there.

Is it possible to "expose" all the methods of a given class ?

thanks
Matt

As a JSON-RPC 2.0 Notification, the request should not contain id field and if remote.notfiy is intentionally to be an interface to send notification.

Reference: http://www.jsonrpc.org/specification#notification

BTW, I love this module. Easy to use and easy to integrate with other transport methods.
Thank you, cheers.

Well, the 2010 JSON-RPC 2.0 specification added batches (more verbose than ours), named parameters and no-response calls (called "notifications"). No implementation I could find can truly behave as a client and server simultaneously, so it's worth rolling our own.

In addition to compliance with JSON-RPC 2.0, we should keep our concept of introspection and use it as a backwards-compatible means to exchange hints about protocol extension support.

This is nice for [Long]WebSocket, but there should be a clear example for batched client-side operation as well, say with jQuery.ajax() for example. This would help the upgrade process for projects which used the batched version prior to this streaming rewrite.

-and/or-

Relying on jQuery for this otherwise stand-alone module in polling mode seems excessive. If users have jQuery available good, but XmlHttpRequest() isn't much of a hassle to use directly. We should also make an example for it.

We could even make our own AJAX module for the purpose of being interchangeable with LongWebSocket as the I/O layer under us if the example becomes too complex. This would be strictly for a request-response scenario, given that for long-poll purposes we now enjoy widespread browser support for WebSocket.

Now that we're more likely to throw information around using JRPC v3, there should be a way to declare functions that aren't expected to respond. This is especially useful on the client side, so that the server could send information at any time in the form of a call and not expect a response at all, which saves memory, bandwidth, and resources on the receiving end.

When initializing JRPC client-side, accept two URLs:

• The CGI request/response URL, if offered (essentially JRPC v2) or null/false otherwise;
• The WebSocket URL, if offered or null/false otherwise.

Also, a flag should describe whether we should long-poll (possibly without any initial payload, i.e. {'JRPC':3.0} without requests or responses, or operate in v2-style batches and only make a request if there are accumulated calls to send.

Long-polling needs a minimum delay to reconnect, to avoid DoS'ing servers, though that delay should be from the last connect attempt, not the moment the response was later received (thus allowing for fine interactivity while protecting servers).

In interactive mode, especially long-poll, it could be useful to still allow batches when the developer sees it fit. For example if I want to make 10 calls right now, it's much more efficient to batch them up and JSON.run() once, even in WebSocket. Perhaps creating JSON.queueCall() / JSON.run() for batch mode (in all 3 modes of operation) and adding JSON.call() in the two interactive modes would make most sense, so call() would be immediate (unless we're batched, where run() is still necessary), queueCall() would force queueing and run() in any of the 3 states would send a batch if anything's in the queue.

If we had remote.shutdown(), we could clear all timers, outbox data, etc. to help garbage collection and flag the instance as moribund to avoid re-populating anything afterwards. This will help server-side.

I forgot to explicitly document how to call one-way in what JSON-RPC 2.0 calls "notifications". Furthermore, we currently set a useless timer in this scenario which needs to be removed.

• Document that call's callback argument is optional if you don't care about or don't expect a return value (although then errors go undetected);
• Throughout .call() we call back without checking typeof next === 'function' first, which is incorrect;
• Create shortcut .notify() which is simply a reference to .call() and document as such, so users of the API can clearly distinguish calls vs notifications.

This sort of goes without saying now that XHR-longpoll and WS are supported, but we want to share as much code between server and client sides as possible.

We also want to publish the server build on NPM and the client build on Bower.

Hi there,

Is it possible to have multiple clients operate the same jrpc server ?

I get a situation where I can connect multiple clients and execute rpc for both clients, however only the most recently connected client will get a message returned.

The oldest client prints out :
{code: -1000, message: "Timed out waiting for response"}

thanks
Matt

There is unnecessary verbosity in v2. Version 3 packets should simply be:

{
    JRPC: 3.0,
    calls: [
        {
            id: ...,
            comp: ...,
            f: ...,
            args: ...
        }
    ],
    results: [
        {
            id: ...,
            ok: bool,
            err: string,
            res: ...
        }
    ]
}

...with no obligation to supply calls and/or results if they would be empty.