Multipeer File System could ping peers whenever new files are added

[drewmccormack]

The CDEMultipeerCloudFileSystem knows when knew files are added, and could send a message to peers when that happens, telling them that it has new files. The peers could use this to trigger a retrieval.

[cflorion]

Hmmm this is kind of how it works today I believe. Maybe you mean putting this logic INSIDE CDEMultipeerCloudFileSystem ? This is not inside CDEMultipeerCloudFileSystem so developers can implement the sync how they want (sync whenever new data is saved, sync every minute or a sync button).

More precisely for now , we subscribe to the notification CDEMonitoredManagedObjectContextDidSaveNotification in MyMultipeerImplementation for instance. [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(pushChangesToPeers) name:CDEMonitoredManagedObjectContextDidSaveNotification object:nil];

And call synchronizeFilesViaMultipeerSession:withSpecificPeers: when the notification is triggered

- (void)pushChangesToPeers { [self.multipeerCloudFileSystem synchronizeFilesViaMultipeerSession:peerSession withSpecificPeers:nil]; }

Would you want to put this logic inside the cloudFileSystem ?

[cflorion]

And what happens in synchronizeFilesViaMultipeerSession:withSpecificPeers: is this:

• the peer sends a status ("here is what I have") to the other peers
• the other peers receive this status and compare with what they have
• it a peer is missing a file he asks the peer he received the status from what it is missing ("give me this, this and this")
• the peer receiving the request send a zip to the requester

[drewmccormack]

I think your original code pulled new remote files, as well as pushing missing remote files. I thought it would be cleaner to just have each peer pull new files from peers, as if they were pulling from a server.

It's cleaner but the disadvantage is that the remote system doesn't know when new files are available. When you are syncing often like you, it is no problem, but with infrequent syncs, or might be nice to have a sort of push notification to peers when new files available, same way a server would do a push notification. Peers can then trigger a file sync automatically.

Drew

On 08 Jul 2014, at 23:07, Florion notifications@github.com wrote:

Hmmm this is kind of how it works today I believe. Maybe you mean putting this logic INSIDE CDEMultipeerCloudFileSystem ? This is not inside CDEMultipeerCloudFileSystem so developers can implement the sync how they want (sync whenever new data is saved, sync every minute or a sync button).

More precisely for now , we subscribe to the notification CDEMonitoredManagedObjectContextDidSaveNotification in MyMultipeerImplementation for instance. [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(pushChangesToPeers) name:CDEMonitoredManagedObjectContextDidSaveNotification object:nil];

And call synchronizeFilesViaMultipeerSession:withSpecificPeers: when the notification is triggered

• (void)pushChangesToPeers { [self.multipeerCloudFileSystem synchronizeFilesViaMultipeerSession:peerSession withSpecificPeers:nil]; }

Would you want to put this logic inside the cloudFileSystem ?

— Reply to this email directly or view it on GitHub.

[cflorion]

Do you mean:

• PeerA has new data created locally
• PeerA send a notification to the other connected peers saying "I have new files: file3, file4"
• (PeerB is one of the other peers)
• PeerB asks for "file3, file4"
• PeerA sends file3 and file4 in a zip to peerB

or:

• PeerA has new data created locally
• PeerA send a notification to the other connected peers saying "I have new files"
• PeerB asks for the new files "I have file1 and file3, give me what's missing"
• PeerA sends file3 and file4 in a zip to peerB

or neither ? :D

[drewmccormack]

I mean the second case. When a new file is added on peerA, it tells other peers "I have new stuff". At that point they just run their normal retrieval and get the new stuff. Would be an easy change I think. Just add one extra message type (eg FilesChanged)

Drew

On 08 Jul 2014, at 23:27, Florion notifications@github.com wrote:

Do you mean:

PeerA has new data created locally PeerA send a notification to the other connected peers saying "I have new files: file3, file4" (PeerB is one of the other peers) PeerB asks for "file3, file4" PeerA sends file3 and file4 in a zip to peerB or:

PeerA has new data created locally PeerA send a notification to the other connected peers saying "I have new files" PeerB asks for the new files "I have file1 and file3, give me what's missing" PeerA sends file3 and file4 in a zip to peerB or neither ? :D

— Reply to this email directly or view it on GitHub.

[cflorion]

There must be something I am missing out because I don't see why we would need a new message type that would do the same as StatusMessage type.

1)What you meant;

2)What I did:

3)A possible optimisation if peerB sends a status before peerA:

From what I understand 1) and 2) do the same. For me FilesChangedMessageType type would do the same as StatusMessageType.

Except that 2) works in all the cases:

• I have new stuff -> send statusMessage
• a peer just connected -> send statusMessage to it
• the user push the sync button -> send statusMessage --> The result is always the same, the remote peer checks if it has all the files or if it has more files it can share with others.

I'll sleep on it.

[drewmccormack]

I think the confusion is that I changed things from your original implementation.

A status message now just results in the new files from the peer coming back to the sender. It doesn't trigger the remote peer to get new files.

When connecting first time, both peers will retrieve files, so no big deal.

But if the peers are connected for a while, they will only retrieve remote files by regular polling (eg a timer). It would probably be better to have a sort of push that triggers a retrieval.

Drew

On 09 Jul 2014, at 00:23, Florion notifications@github.com wrote:

There must be something I am missing out because I don't see why we would need a new message type that would do the same as StatusMessage type.

1)What you meant;

2)What I did:

3)A possible optimisation if peerB sends a status before peerA:

From what I understand 1) and 2) do the same. For me FilesChangedMessageType type would do the same as StatusMessageType.

Except that 2) works in all the cases:

I have new stuff -> send statusMessage a peer just connected -> send statusMessage to it the user push the sync button -> send statusMessage --> The result is always the same, the remote peer checks if it has all the files or if it has more files it can share with others. I'll sleep on it.

— Reply to this email directly or view it on GitHub.

[drewmccormack]

Closing this, because Florian has already made an improved backend.