Re: [alto] Issue about incr-updates-sse update stream control design

["Y. Richard Yang" <[e-mail]>]

Thanks a lot for the points, Dawn.

Please see below.

On Sat, Mar 3, 2018 at 7:57 AM, Dawn Chan <[e-mail]> wrote:

> Hi Jensen and Richard,
>
> Here are some of my ideas about the problem.
>
> Actually, the solution for option 1 is already mentioned in Section 8.6 of
> the draft:
> “If a request is successful, the server returns an HTTP ‘204 No Content’
> response with no data.  If there are any errors, the server MUST return the
> appropriate error code, and MUST NOT add or remove any resources from the
> update stream.  Thus control requests are atomic: they cannot partially
> succeed.”
>
> Here, the appropriate error code is returned in the HTTP response.
> Actually, an HTTP response has to be sent to the client whether the request
> is successful or not.
>
> The approach that the server also notifies client outcome in the update
> stream can guarantee that the request does succeed. So I think it is better
> to use them both.
>
> This way, if the request is processed successfully, the server will return
> with an HTTP “204” no content and a message in the update stream. If the
> request fails, the server will only return an error with ALTO error code in
> the HTTP response.
>
>
It is clear that using both, as it is in the current design, is an option.
Make sense to others in the WG?


> Another issue in the draft is the name of “client-id”. The name
> “client-id” looks more likely to distinguish ALTO clients, rather the
> different requests of different resources. So, I think it might be better
> to use another name, maybe “request-id”, to replace “client-id”. Do you
> have any better names?
>

Since it names an update stream, how about stream-id?

Richard

>
> Dawn
>
> On 3 Mar 2018, at 7:30 AM, Y. Richard Yang <[e-mail]> wrote:
>
> Hi Jensen,
>
> Good question! Let's see the design space:
> 1. Client can send "add" or "remove"; since HTTP requests are "one-way",
> this needs to use a new control channel--a new HTTP request
>
> 2. Response option 1: Server notifies client outcome in the HTTP response
> by using a HTTP response code;
>
> 3. Response option 2: Server notifies client outcome in the update stream;
>
> Note that we can have 3 options: (1) option 1 only; (2) option 2 only;
> (3)  both.
>
> Option 1 only may have a concurrency issue, depending on the specific
> design and semantics. Consider two semantics:
>
> 1. Server responds *only after* the last updates have been sent
> successfully. This will lead to synchronization of likely two processes at
> the server; hence the guaranteed serialized sequence is:
>
> client sends remove request -> server (process 1) processes the request ->
> server (may be process 2) flushes all outstanding updates to client ->
> server (process 1) notifies client by returning in the http request.
>
> The price here is that the server process structure can be more complex.
>
> 2. Server responds *immediately* (i.e., not blocked by flushing and ack of
> all pending updates), and hence, the semantics is that although the
> client gets a "remove" success, updates may continue to arrive; hence the
> client code needs to be careful to handle the issue. It is not clear when
> the client can be notified that the buffer is flushed indeed.
>
> Option 2 does not have the preceding issue: the server HTTP response only
> acknowledges that the "remove" request is received successfully and can be
> processed, but not that it is cleared.
>
> But thinking about the issue one more time, we can use option 2 only, but
> then the document need to make clear that the client can handle remaining
> updates gracefully---just as after TCP close but data can continue to
> arrive. Is this a design that you appreciate more?
>
> Richard
>
>
>
>
> On Fri, Mar 2, 2018 at 10:57 AM, Jensen Zhang <[e-mail]>
>  wrote:
>
>> Hi incr-update-sse authors and all,
>>
>> I have a question about the current update stream control design in
>> incr-updates-sse.
>>
>> In the last paragraph of Section 7.6.2, the document writes
>>
>> "When the client uses the stream control service to stop updates for one
>> or more resources (Section 8
>> <https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-09#section-8>),
>> the ALTO server MUST send a control event (Section 6.3
>> <https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-09#section-6.3>)
>> whose "remove" field has the client-ids of those resources."
>>
>> As section 7 defines "Update Stream Service", this paragraph means the
>> ALTO server MUST send a control event in the update stream to notify the
>> client the status of a stream control service request. Why do we want to
>> use a different channel to return the output? Why not return this control
>> event from the response of update stream control service? I feel it will
>> introduce the unnecessary complexity.
>>
>> Can anyone of authors elaborate the reason for this design?
>>
>> Thanks,
>> Jensen
>>
>
>