[Ndn-interest] Accessing historical data using ChronoSync

Wentao Shang wentaoshang at ucla.edu
Fri Oct 21 20:25:29 PDT 2016


> On Oct 21, 2016, at 2:23 PM, Gusev, Peter <peter at remap.UCLA.edu> wrote:
> 
> Hi all,
> 
> I’m curious whether there is any work done on the issue I’ll explain below. The issue concerns fetching historical chat data that was generated while a user was gone from the chat. This means two cases:
> 
> #1 Newcomers
> In current ChronoSync implementation, when a newcomer wants to join existing chat (i.e. chat that was created earlier by someone else), she issues initial sync interest with “00” marker (or any initial marker defined by implementation). Then, she waits for the current sync state data object (which contains current digest tree). This sync state data object can be sent out only by one of the currently active members (in the chatroom). Hence, the problem - if there are no active chat members (meaning, everyone already left the chatroom), newcomer will never receive the latest sync state object and eventually, will initialize a new digest tree from scratch, thus leaving herself without knowledge of the previous chat history.
> Basically, I’m trying to figure out now how to prevent this and allow newcomers to retrieve chat history that was generated before them, without relying on the presence of active chat members.
> 
> #2 Returning users
> Similar case, but simpler, with returning users. How do returning users (those, who were in the chat earlier, left eventually and now have joined chat again) can fetch all the data that was published while they were gone? 
> IMPORTANT NOTE: For both cases (#1 and #2), I assume the presence of the "network persistent storage" which stores all chat and sync data. With such assumption, I think, fetching of historical data can be resolved rather straightforwardly: returning user instead of issuing initial sync interest (with “00” marker) issues sync interest with the digest, known for her when she left. Upon receiving sync state data, she updates digest tree with new changes and issues another, new sync interest. By repeating these steps sequentially, returning user is able to “fast-forward” to the latest sync state and successfully join the chat.
> 
> Back to the case #1 -  after some thinking on the possible implementation workarounds, I came with few alternatives, neither of which seems satisfying to me:
> 
> 1/ Publish initial sync state data (initial digest tree generated by chat’s creator) under the name with initial marker (“00”). 
> As this data will go to the “network persistent storage” (i guess this will need to be clarified further on what does it actually mean), newcomers are able to receive data for their initial interests without requiring any active members in the chat. Upon receipt of this data, they “fast-forward” in a similar way as returning users do.

Off the top of my head: why not have the new comer send a sync Interest without any digest? This interest will fetch whatever sync reply out there and the new comer can start from there. It may not work if the sync history diverged at some time and a recovery was performed to merge the conflict. But I didn’t think through this very carefully… 

> 
> 2/ Publish versioned meta-object under the name with initial marker (“00”) which encapsulates latest sync state object (or it’s name) so that newcomer is able to use exclusion filters and/or rightmost child selector to quickly "jump" to the latest sync state object.
> As this meta-object needs to be re-generated every time sync state object is updated, it seems that there might be potential difficulties in cases of simultaneous data generation and recovering.
> 
> 3/ Use digests, where every newly generated digest comes after previous one in lexicographical order.

How do you guarantee lexical order using digests? They are just random numbers generated by the hash functions… 

Wentao

> That way, newcomers simply use RightMostChild selector for initial interest (instead of “00” marker) to fetch latest available sync state. 
> Didn’t do any research yet on whether this is possible in ChronoSync case (this seems relevant).
> 
> Please, let me know what you guys think on any of this. Any input will be appreciated.
> Thanks, 
> 
> -- 
> Peter Gusev
> 
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
> 
> Software Engineer/Programmer Analyst @ REMAP UCLA
> 
> Video streaming/ICN networks/Creative Development
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest





More information about the Ndn-interest mailing list