WebSocket - Proposal to including client request id in subscribe, unsubscribe, get, set messages

Hi,

[I've started a new thread as the previous one was being used for both
WebSockets and Security/Certificate discussions]

Thanks very much to Rudi and Powell for the feedback on the call re. the
client passing a client request id to the server on subscribe, get, set
messages. The server then echo's the client request id back in the response
to make it easier for client's to link requests and responses.

I would be happy to amend the draft that Adam and I have prepared to
include 'requestId'. Intention would be that for subscriptions, the
'requestId' passed in the subscription request includes the clients
definition of the subscription id (as Rudi proposed) and for get and set
messages it is the clients unique id for the particular get/set request.

If there is a better name than 'requestId', please do let me know (trying
to keep it short and for simplicity, to allow same id to be used on
subscribe, unsubscribe, get and set)

>From server perspective, implementation is simple, for subscribe, get and
set it will just echo back the requestId value in the response. For
unsubscribe, the client could pass this to unsubscribe (as Rudi proposed)
and value is echoed back in the unsubscribe success response.

Could you please confirm that this addresses the concerns you raised or
please add to this new thread if it doesn't.

Thanks very much and regards,

Kevin




Hi Rudi,

Thanks for the feedback, my comments are in blue below.

Client-side Subscription ID
--------------------------------------
The server returns an acknowledgement when a subscription attempt was
successful. The acknowledgement contains a server-side subscription ID and
the subscription parameters so that the client can identify the request. I
suggest for the subscription request to contain a client-side subscription
ID/handle. That would alleviate the client from parsing the subscription
parameters and matching them to the request. That client-side subscription
ID could also be included with the data sent to the client.

Agree that we could do this, but my preference would be for the
subscription id to be server generated (as this is simpler, please see also
answers to other questions). The server can then guarantee uniqueness for
that websocket session. Personally, I don't think it would be too onerous
for client to link the server subscription id to the using the path. In the
real world, if I subscribe to receive a magazine in the post, the publisher
decides what the subscription id is. This follows the same pattern.

Repeated Interval Subscription
--------------------------------------------
The subscribe action in the table does not define what happens when the
client sends repeat subscription messages with different intervals for the
same signal path. Would that result in another subscription or in a change
of the interval of the previously made subscription? I would think that it
should change the subscription interval. However, if we used a client-side
subscription ID and the client uses a different ID for the subsequent
subscription request to the same signal with a different, or essentially
any interval, would that result in a change of the previous subscription
despite the different client ID (eventually with an updated client-side
subscription ID)?

If the client sends multiple subscriptions to the server for different
intervals, then the server would respect the request and create separate
subscriptions with different ids, and use the different id to identify the
response. Slightly unusual case, but for all the server knows, the client
might have a legitimate reason for wanting to see the same signal at
different intervals. Similarly, a client could subscribe using onchange and
interval to obtain data for the same signal. These two requests would
result in two independent subscriptions. This keeps it simple on the server
side. The server just respects the clients wishes.


Repeated Onchange Subscription
-------------------------------------------------
Are repeated onchange subscriptions supported for the same signal but with
different above and below thresholds? One could think of multiple
subscriptions to define bands of engine.rpm: (above: 0, below: 1000),
(above: 1000, below: 2000), ... If that is possible then overlapping
intervals/bands would result in multiple messages?

Yes. This keeps it simple again. If the client wants to create multiple
independent subscriptions, then thist is allowed.

Thanks for the quick feedback, look forward to speaking to you in a few
minutes on the call.

Kind regards,

Kevin





*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR