Implement mechanism for providing unique ids for json rpc clients

[sleshchenko]

Now id is a part of endpoint address and generation of it is a responsibility of the client. But there is not a way to guarantee that different clients generate a unique identifier.

There are few ways to be sure that different clients use unique identifier:

1. Implement providing identifier from a server when the connection is set up and implement a mechanism to reconnect as existing client. Something like:

• Client connects to a websocket endpoint;
• Server establishes connection and send generated id to client;
• Client receives id and store it;
• If the connection is interrupted, client reconnects and somehow specify its identifier (like query param or by sending a special message).

2. Implement rest service that will generate a unique identifier for clients. Then:

• Client request identifier for itself and store it;
• Client constructs endpoint path by adding received identifier;

3. Also we can investigate if we could robustly identify client without any interaction with him, for example getting client's unique identifier from websocket connection session or something like that.

Second way looks like easier to implement but there still is no guarantee that clients will use implemented service for generation of identifiers. And the second approach force clients to use an identifier on another hand first approach provides identifiers just like additional functionality for reconnection and clients don't have to use it.

[benoitf]

what is the implementation choice that has been picked up ? between choice 1, 2 and 3 ?

[dkulieshov]

@benoitf It is not yet decided completely, there appeared some technical impediments so we will probably have something in the middle of the first and the second option. I will provide brief spec draft as soon as the prototype will be tested.

[benoitf]

@dkuleshov thx for the answer, as I noticed that it was in the current-sprint/in-progress I thought it was decided

[dkulieshov]

Adding brief specification from the PR, there is more info in comment in PR itself

What does this PR do?

This PR provides a new way of interaction between websocket server-side and client-side.

In order to identify a client on server-side to associate with it some processes or data we must have a unique client ID. In previous version client itself was responsible for ID generation and providing to server-side, that approach had its obvious shortcomings.

The new approach rearrange responsibilities in a such way that server-side now have a centralized way of generating a unique identifier, while client can get that identifier and use it for its identification further. The JSON-RPC service at the moment has the following api:

• method name: websocketIdService/getId
  method params: none
  method result: String
  description: this method must be used by a client in order to get identifier that will also be associated with current websocket session.
  example:

request

{
    "jsonrpc": "2.0",
    "method": "websocketIdService/getId",
    "id": 0
}

response

{
    "jsonrpc": "2.0",
    "result": "529345982734",
    "id": 0
}

• method name: websocketIdService/setId
  method params: String
  method result: none
  description: this method must be used by a client in order to make the provided client identifier associated with current websocket session
  example:

request

{
    "jsonrpc": "2.0",
    "method": "websocketIdService/setId",
    "params": "529345982734"
}

So briefly the workflow is the following:

• Initially client has no websocket identifier
• When it establishes a first websocket connections and the fist websocket session is initialized it calls a corresponding JSON-RPC service (websocketIdService/getId) to get a unique identifier
• For all further websocket connection establishments (e.g. reconnection, new endpoint, etc.) it must call a corresponding JSON-RPC service (websocketIdService/setId) in order to identify itself in a newly initialized sessions.

Important comment

In the most basic case when a client establishes a connection server side generates a unique ID which is associated with a session and no client interaction is required at all. However if you need to identify the same client for several websocket sessions (for example when you have several endpoints in a single application) you obviously will need some cross-session identifier and for those purposes we have websocket id service.

So answering your question, when client does not call setId it should work just fine within the single websocket session. When client's logic involves several websocket sessions you have to use cross-session ID.

[garagatyi]

@dkuleshov @sleshchenko Can we close this issue?