right pattern for incremental updates (and getting initial state)

[BrannonKing]

Suppose I have a situation where I need to keep a client-side object up to date with a server-side object. The object is large (say 100KB). I intended to subscribe to incremental updates coming from the server. However, I need the entire initial state immediately after being connected. Is there some way for my callee to know he was just connected? Or do you use a monitor event externally and have that trigger some method on the callee? Or do you have the server use a "new connection" event to automatically send some data to that client? Is there even a way to make the server publish something to a specific sessionID? Or do you use a key-frame approach? Which is easiest with WampSharp? Just looking for suggestions, thanks.

[darkl]

I'm not sure I entirely understand the question, but one popular approach is to subscribe to the TopicCreated and WampTopic.SubscriptionAdded event handlers. In the SubscriptionAdded you have access to the remote subscriber and you can send it a message containing the initial data. Probably this should be one separate topic since I think that in the meanwhile other events published will be received by the subscriber.

[BrannonKing]

Sorry I haven't worked on this for a year. It sounds like you were proposing a push model for initial updates rather than a pull-after-connect approach. That would probably work similarly, but there would still need to be some additional coordination.

Consider the situation where there are 100 instances of something. The client A connects the first time containing nothing. The server then sends him all 100. The client A has those items cached locally. Occasionally he gets items replaced as other clients change them. Later, somebody temporarily pulls the cord. The client A gets disconnected. After a few seconds he gets reconnected. What should happen? It's possible some other client added/modified/removed items during the disconnect. The client A would have to clear his cache when he got disconnected or the server would have to send some message saying to clear things out before sending the 100 items again. Alternately, the server could keep some state on what each client knows. But if it's the server itself that goes down, he wouldn't know that state upon returning to service. I guess I still don't see a good way to do a server push-on-connect with a single topic.

[darkl]

A year has indeed passed. However, new features had been recently proposed to WAMP advanced profile which try to resolve these sort of problems. See here and here.

Elad

[oberstet]

The proposed "last will" (aka "testament") feature is about having the router automatically produce and dispatch an event when a session dies that has previously published an event that was marked as being its testament.

The proposed "session resumption" feature is about keeping alive a router side representation of a session when the transport running the session is lost. It is supposed to a) remember the subscriptions and registrations the session with the lost transport had, and b) queue events dispatched to the (currently unreachable) session. Later, when the session reconnects over a fresh transport, the router may automatically dispatch the queued events to the client.

The queuing of events to a specific session is different from the "event history" feature, as the former will remember exactly which events to dispatch upon session resumption, while with "event history", a client needs to decide what to request. However, queuing is also more resource intensive.