On 15 December 2010 00:13, Tad Glines <[email protected]> wrote: > On Mon, Dec 13, 2010 at 9:18 PM, Alex North <[email protected]> wrote: >> >> That's fuzzy because the proposal gives no such guarantee and a client may >> not rely on ordering between the wavelet channel and submit delta responses. >> This is based on the existing implementation. If WIAB happens to order them >> consistently then that is by chance (an artifact of websocket?) rather than >> design. >> >> A client doesn't need to cache all received updates, only those that >> arrive after a gap in the contiguous delta version sequence. The >> WaveletDeltaChannelImpl class in WIAB handles this ordering. Updates are not >> unnecessarily delayed in practise as the submit response usually does reach >> the client before the next update. >> > > OK. I get it now. Sorry for the slow uptake. The idea of a gap as being > treated as a think in itself is just awkward, but, it works, so that's fine. > > >> As you note, adding an ordering requirement would restrict the transport >> to be over a single connection that could provide such ordering (so you >> couldn't use a universally compatible hanging GET / HTTP POST combination >> without adding virtual channel overhead that essentially leads to message >> caching). A possible alternative would be to ignore the submit response and >> insert a message into the wavelet stream representing the client's own >> delta, perhaps a WaveletUpdate with no delta. However since the submit >> request must get some kind of response anyway (for errors) it seems most >> efficient to include the application metadata in this response, directly >> associated with the request, than insert another message into the update >> stream and ignore successful responses. >> >> The equality comparison mechanism that Torben mentions is implemented and >> works too. It's currently engaged only when connections bounce and the >> client misses submit response messages, as the equality test can be >> expensive. Essentially the server filters a client's own deltas as a >> bandwidth-optimising service to the client. >> > > Can you provide a bit more detail on when delta comparison is used. When > does the client switch to delta comparison, and when does it switch back to > gap detection? >
The comparison I was thinking of is in ConcurrencyControl.detectEchoBack(). This is executed only in the initial stages of resync when the client has queued deltas to (re-)send. Gap detection always happens, down in the delta channel. I see it also happens in DeltaPair.transform(), whenever OT is performed. This sounds bad, but in practice the comparison is cheap as the author of incoming operations usually doesn't match the author of client operations. > > -Tad > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
