Java File syncing tool. Target: java 8
fmap_examples.zip fmap-1.0.1.jar is included in the example. 08.04.2024 fmap-1.0.1.jar sha256: 6a92f828dc4118ffca16aa28d78148532acde17321ffa8a1a9382d833457906d 27.03.2025 fmap-1.0.jar sha256: 42fa35e43d8c16e5fe4f49cf983b93bc4ccf420be9a09124e5481f8271ef8d31 First released: 27.03.2025 A p2p file syncing tool that may be used to replicate: - files and directories of fixed size - database that can be restored only by its log files - other logs - files that only change by appending data at the end fmap is ment for small network of peers, where all peers are connected to each other to balance the traffic. There are no special peers. The one that has the original is presumed to be main. A peer connects to entry node defined in the config, and then to all peers in the network. fmap is write-once, there is no remote delete or update. If the original changes it has to be share again with different rid/rs_info. If rs_info does not match the rid it will be rejected. If two rs_infos have colliding rpaths, one could overwrite the other. To avoid this choose unique paths, names and IDs. CONFIGURE THE NODE - create FNodeConf - set app directory and sync_directory - set the node port and IP - from the replica set the remote port and IP - set flags: open, read_only app_dir app may store some config or other info sync_dir where all the synced data is stored rpath relative path to sync_dir set_open tell other peers if they should attempt to connect to this peer default is "true/open" set_read_only this node will ignore incoming data, to prevent some changes by mistake default is "false" - accept incoming data FMAP rid is calculated hash from rs_info file itself using SHA256 and can be changed. pieces hashes are calculated using SHA1 and are part of the rs_info format Create rs_info Use the fmap.ri_tool to create rs_info register_ri() - calculate rid from rs_info and call register(rid, rs_info) - in case of trusted network rs_info is exchanged directly between the peers - in case of untrusted network rs_info is exchanged through trusted node sync() - starts syncing this rid with the other peers get_peers() get all connected peers get_peers(rid) get peers interested in this rid FMAP_EXT Key features: - rid is the same as the rs_info name. - a replica may start from zero or catch up from any position - a replica may request previously closed file to be reopened. In case of missing files form a sequence. The peers will reopen if replica calls sync(rid). - maintains the last good flush position and checksum (Adler32) - maintains consequent checksums of all pieces to the last append - in case of error the replica will continue from the last good append - there is no confirmation on any piece/append receive. Only when finalize() is called by main peers online will wait and agree on closing the rid sync() Causes all peers to start the same rid. If called my main it will start to share, if called by replica it will request the main to share. auto sync - if any peer starts rid, it is synced by all peers, may be original or a replica - if we receive append auto finalize If one peer calls finalize(), all peers check if they are in sync, mark the rid as final, wait for the other peers, and close. Only the original should call finalize(), it is persistent and you cannot call append() after that. It an error to calls finalize() by a replica. It may cause peers to finalize the rid prematurely. append() By calling append() to main we create local copy which is then synced with the replicas. A replica should not call append(). If the main is gone, you can decide which replica that has the latest data may take over. finalize() - mark rid as final - waits for peers to sync - closes the rid - should be restarted by other peers - its persistent close() - doesn't mark rid as final - doesn't wait for peers to sync - close now - can be restarted by this peer - not persistent set_callback() is global. Get notified when rid is finished and ready to use.
|