Hi Martin and all, A new revision (-15) has been submitted to address the Httpdir last call review.
Highlights: - Persistent connection and related sections are removed. A short discussion is added to the appendix explaining the reason. - A new heartbeat request is introduced to check client liveness for a TIPS view. - <tips-view-uri> is now an absolute path to enable potential scoping with subdomain. - Specs for push-mode TIPS and related sections are removed, except a short discussion left in the appendix. Please let us know if the proposed changes resolve the issues. Thanks! Best, Kai > -----Original Messages----- > From: [email protected] > Send time:Thursday, 10/05/2023 16:25:23 > To: "Martin Thomson" <[email protected]> > Cc: [email protected], [email protected], > [email protected], [email protected] > Subject: Re: [alto] Httpdir last call review of > draft-ietf-alto-new-transport-14 > > > > > > -----Original Messages----- > > From: "Martin Thomson" <[email protected]> > > Send time:Thursday, 10/05/2023 11:26:32 > > To: kaigao <[email protected]> > > Cc: [email protected], [email protected], > > [email protected], [email protected] > > Subject: Re: Httpdir last call review of draft-ietf-alto-new-transport-14 > > > > On Thu, Oct 5, 2023, at 13:53, [email protected] wrote: > > > We will really appreciate it if you can point us to any work that has a > > > better > > > design, as it looks like a generic problem. > > > > The namespacing issue is easy to address using the design I sketched out. > > That's a pretty common pattern. > > > > The heartbeating mechanism you describe could work, though it could end up > > being wasteful. > > > > There is an alternative here, which is to avoid server-side state and put > > the necessary state into the URL you return to clients when "creating" a > > view. > > Then you don't need to rely on liveness checking so much. You can have > > server > > side caches for any essential state that carries between requests, but you > > don't > > rely on that state being present. Any state can be cleared as necessary > > (on a > > timer, say), without needing constant pings, because it can be recovered if > > necessary from the URL. If you can get away with having no server-side > > state at > > all, this is even better, but I don't know how much these views represent > > substantial investment in computation or state such that it might be > > awkward to > > transfer that with every request. > > Unfortunately this is not feasible in our case. The fundamental states include > > 1. resource of interest > 2. parameters (e.g., filters) > 3. data & updates of the interested resource based on the parameters > 4. the current version of the client's data > > We already encode 4 in the URL but the first 3 (especially 3) are the most > resource-consuming states. Unfortunately 3 can only be maintained by the > server and depend on 1 & 2. > > In the ideal case, the client should release the resources when it terminates. > However, in case of failure or DoS attack, the heartbeat mechanism is needed > to identify resources that are no longer being used. > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
