Question: Spec Get vs Spec Subscribe ONCE

[amamory]

I've been discussing with colleagues about the interpretation of Get and ONCE RPCs, with focus on their differences. Basically we end up with two possible interpretations of the ONCE RPC:

Interpretation 1) The server receives the request, go through the subscription list and fetches the data for all items in this list, populates the response msg and send it back; There would not have the need to save the subscription list according to this interpretation. This behavior would be pretty much like a Get RPC. Which is weird by itself ... why should the spec include two redundant operations ?!?!? The data value (and its timestamp) would correspond to the value at the moment the subscription request is received.

Interpretation 2) The server receives the request and ACTUALLY does subscriptions, waiting for the NEXT event of each item in the subscription list. Every event corresponding to the subscription list, its data is fetched, its path is removed from the list, the server populates the response msg and send the data back. Repeat it until the subscription list is empty, i.e., one event was capture for each path in the subscription list.

The point is that it seems that there is not much evidence in the specification to FULLY support none of those interpretations. The key question that remains not clear in the spec, is WHEN the response is sent in both cases ?

---

There other parts related to these RPC spec that add up to the confusion:

"Get is not well-suited for retrieving very large data sets, such as the full contents of the routing table, or the entire component inventory. For such operations, the Subscribe RPC is the recommended mechanism, e.g. using the ONCE mode"

Ok, it says that one might be preferable in case of large msgs, but WHY ? would be this sentence that explains the reason?

"updates_only - a boolean that causes the server to send only updates to the current state. When set to true, the target MUST not transmit the current state of the paths that the client has subscribed to, but rather should send only updates to them. "

If the answer is yes, it would be nicer to have a reference to updates_only when the performance issue it mentioned.

---

The following sentence seems to imply that the second interpretation is correct, but again, it also seems rather incomplete and open to different interpretations in the case of ONCE:

"Where a leaf node's value has changed, or a new node has been created, an Update message specifying the path and value for the updated data item MUST be appended to the update field of the message."

Any additional evidence would be appreciated !

best regards,

[hellt]

@amamory Subscription ONCE is a streaming RPC, which means the notification messages may be streamed to the requesting client as the internal process fetches data. Get RPC is a unary RPC, which means the server needs to process all the requested data containers/leaves and send a single response back to the caller.

This is why requesting bigger portions of config/state is more effective with Sub ONCE

[amamory]

Thank you @hellt

If I understood your response, you are referring to the question related to performance, Why ONCE has better performance than Get. Right ?

And how about the main question: WHEN the response is sent in both cases ?

Let's assume the server receives a ONCE request with 3 paths in the subscription list. When is the response(s) generated ? 1) immediately after the request arrives at the server (like a Get ?, then sync_response is sent. 2) once the 1st path of the list changes, all paths are updated to send the response, then sync_response is sent. 3) once the 1st path of the list changes, JUST the changed path is updated to send the response, then sync_response is sent. 4) a response is sent once after EACH path change. When all paths changed once, sync_response is sent. 5) none of these options above :)

[robshakir]

ONCE subscriptions:

• retrieve the current value of the leaves matching the path(s)
• sends them immediately on the wire - across as many Notification messages as the server wants to send them across (in the limit, one per leaf)
• closes the subscription

Get responses

• retrieve all the current values of the leaves matching the path(s) in the request
• marshals them into the specified encoding (e.g., JSON_IETF) matching the specified paths
• sends exactly one GetResponse containing all the values that were requested in the GetRequest.

In a client that has some data structure that it is unmarshalling into, the end result of a Subscribe ONCE and a Get RPC are the same, the current value is retrieved - although Get is intended to provide a consistent snapshot of data, whereas a ONCE may return >1 value per leaf if there are changes during the lifetime of the ONCE.

We debated not including Get in the specification -- because the two results can be equivalent, however, especially for the config use case, there was a desire to be able to pull the configuration that was pushed directly from the device in a single snapshot without unmarshalling leaves. Since Get has a significant potential memory cost at the server if it needs to retrieve a lot of data from disparate sources, hold it in memory whilst marshalling, and then send to the client, ONCE avoids this overhead and in practice we have found useful for subscribers that are clients of a collector who want the current state (and no future updates). Hence, both are included in the specification.

[amamory]

thank you very much @robshakir , your insights added some important information to help in the interpretation.