Sebastian,
The alternate approach -- client sends a new ALTO request to get the
updates -- has more overhead than simply creating a new TCP stream.
First, the client must tell the server which version the client has.
That¹s easy for tagged resources, like network maps. But for cost maps
(etc) we would have to add a tag or some other version ID.
Second, the server would have to maintain a log of all changes, just in
case a client asks for updates relative to some previously returned
version. And the server would have to maintain that log even if no client
ever asks for an incremental update.
Third, with that approach, it would be very difficult to provide updates
for POST-mode requests.
Of course the server could delete the old tail of the log, and if a client
wants updates, the client could set a flag in the initial request warning
the server.
For comparison, with the SSE approach, the server does not need a change
log. Instead, for each resource, the server keeps a list of active update
streams for that resource. Whenever the resource changes, the server just
writes the update to those streams. In effect, the network TCP buffers
become the log. And there is zero extra overhead when there are no update
streams.
Incidentally, my first approach to incremental updates was very much like
that: the server returned a time-stamp for resources for which a client
could return updates, and clients polled for updates. Once I discovered
SSE, I gave up on that approach.
- Wendy
On 09/08/2016, 07:31, "Sebastian Kiesel" <[email protected]> wrote:
>>
>>>> ***** I am not really convinced that in every scenario sending a keep
>>>> alive message every 15 seconds is more efficient than the client
>>>>asking
>>>> for updates in similar time intervals.
>>>>
>>>> Keep-alives are much more efficient, because they just send 10 more
>>>>bytes
>>>> on an existing TCP connection. Eg, one message. A request requires
>>>>setting
>>>> up a new TCP connection. That takes several messages, involved
>>>>allocating
>>>> new ports, etc. It is a lot more overhead on both the client and the
>>>> server.
>>>
>>>You are right, opening a new TCP connection every 15 seconds is less
>>>efficient than sending 10 bytes every 15 seconds over an existing
>>>connection, But there may be a break-even point ... What if I want the
>>>updates only every 120 seconds? Is one new TCP connection more
>>>effort than 8 keep-alives? Or 16?
>>>
>>>Maybe it is not worth the effort of changing the spec and adding some
>>>explanation is the better approach, but the current document leaves some
>>>feeling of strange asymmetry in me - one mechanism optional, the other
>>>one mandatory without a good explanation why.
>>>
>>>Sebastian
>>The keep-alive time is in the SSE specification:
>>Legacy proxy servers are known to, in certain cases, drop HTTP
>>connections
>>after a short timeout. To protect against such proxy servers, authors can
>>include a comment line (one starting with a ':' character) every 15
>>seconds or so.
>
>yes, the 15 seconds is in the SSE spec.
>
>that means, if I need updates every X seconds, I will either recveive
>X/15sec keep-alives per update period (and get the updates as the server
>generates them), or I will have to establish one TCP connection per
>update period (and explicitly ask the server for updates).
>
>With growing X, there will be a break-even point where the second
>approach will become more efficient. The question is, if we are
>beyond that point, could there be cases where JSON merge patch
>still makes sense?
>
>Thanks
>Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
