Hi Börje, I am not familiar with the old darft (draft-madhavan-alto-subscription-01) you just mentioned. But if you are talking about the pub/sub mechanism in ALTO, I believe the SSE document (draft-ietf-alto-incr-update-sse-13) is a solution. The SSE document defines a new service which allows the ALTO client to subscribe the real-time update of ALTO resources, and allows the ALTO server to publish the update via the server-sent event stream. And the update can be incremental, which means the ALTO server will only publish the diff patch of the subscribed resources without the JSON nodes that have not changed. This document is already in WG Last Call now.
However, I think the real-time data retrieving is still an interesting topic. Even if we have the pub/sub mechanism, several issues on the real-time data still remain: 1. Currently, there is no mechanism to make the client and the server agree on how frequently the update should be triggered. It is not expected if some data will be updated very frequently so that when the client receives the update it is already expired. 2. The unreliable pub will make the client and the server inconsistent. The thing comes worse when there are multiple dependent resources subscribed. If one resource is updated successfully but its dependency fails to be updated, the client will get inconsistent information. 3. The two issues above can be combined. Consider the case: when the client receives the update of one resource, the update of its dependency is already expired. Those issues do not come from the pub/sub mechanism, but the general real-time data updates. I have some rough ideas about them but no complete solution so far. Maybe the authors of SSE document can say more words. Best, Jensen On Tue, Dec 4, 2018 at 7:53 AM Börje Ohlman <[email protected]> wrote: > I’m interested in finding out if there are thoughts on making it possible > to use ALTO for realtime data in the future, or at least possible to use it > for data that is being updated quite frequently. Examples of such data > could be available bandwidth on links, available storage capacity in caches > or CPU load in processing resources. > > One possible way to enable such use of ALTO could be to provide a pub/sub > option for communication between ALTO clients and servers. Another option > is that clients polls the servers at certain intervals. While the pub/sub > alternative would be nice it probably would mean substantial changes to the > ALTO architecture and protocols. I found an old (2012) draft proposing this > draft-madhavan-alto-subscription-01. Does anyone know if this work has > continued in some shape or form? If not, does anybody have any history to > tell about it? The problem the draft is primarily addressing is to avoid > multiple redundant requests for parameter values that have not changed. > > I would like to propose a more lightweight mechanism to reduce this > problem. We could introduce the possibility for responses from ALTO servers > to indicate an expected freshness period for the returned value giving the > client a hint to when it makes sense to make the next request. > > I by no means consider myself an ALTO expert, so if this functionality > already is provided in the existing protocols or it has been already > discussed at length, please inform me and accept my apologies for wasting > bandwidth on the mailing list. > > Börje Ohlman > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
