Introduction

 

File Collaboration was built as a PeerLink solution and complies with Peerlet conventions. Common to all PeerLink solutions is the notion that some functions are centralized while others are distributed.

 

File locking for example, is a principle feature of this solution that has both central and distributed aspects. The access detection mechanism that is triggered in response to an opening file is deployed in the PeerLink Agent, presumably on each participant host storing files of interest. The lock manager is a centralized component running at the PeerLink Hub that is notified of opening files.

 

We describe some scenarios below to further detail how collaboration functionally overlays the PeerLink architecture.

 

 

Step 1: Session Start

 

At the start of a file collaboration session, the Peerlet starts the initial synchronization process by issuing a request to scan each host participant's Root Folder recursively for file content. The scans are performed at the Agents and results are dispatched back to the PeerLink Hub for merging and file conflict resolution. Transfers are then issued to the Agents to synchronize their hosts' root folders. While the initial synchronization process is performed in the background, the Agents are directed to start detecting access and change events on their respective hosts.

 

 

 

Step 2: File Lock

 

Files will be opened by users during the course of a file collaboration session. When a file opening for modification is detected by an Agent, the Peerlet at the PeerLink Hub will be notified of the occurrence and effectively issue a lock for the analogous file across the session. The issuing host contains the source instance of that file for the time it remains open, implying the remaining hosts' copies are designated targets. Only one source instance is allowed for any given file in a session.

 

Note: If a file is opened in read-only mode or if the application that opens the file does not acquire a read-write lock on the file (e.g. NotePad, WordPad, etc.), the lock will not be propagated to the Target Hosts.

 

When a source copy is closed with no modifications, the target files will be released across the remaining hosts in the session.

 

 

 

Step 3: File Transfer

 

When a source instance is closed with modifications, a synchronizing transfer is issued. The session first acquires a lock on the source instance to facilitate a stable transfer. The locks on the target copies are preserved during the lock transition at the source. The revised source content is propagated to the target instances and the locks are released. Transfers are conducted only among Agents, but coordinated through the PeerLink Hub.