Peer Store

Peer information is managed by a “store” that uses sqlite as backend for persistence. Current implementation merges the store into the application class.

The class also stores the uuid of the “local peer” (the unique identifier other peers use to indicate this peer). While most of the times this will be a proper uuid4, other strings can be used. The class stores the value as bytes, with string converted to bytes by the uuid property using the UTF-8 encoding. The identifier should be at least four (4) characters long in this case. If no uuid is present then uuid.uuid4().hex will be used to generate one in create_meta_table().

Code can add and remove peers using the dedicated methods: add_peer() and take_peer(). If you are subclassing this class note that these methods are NOT called when the database discovers new peers in the database.

Convenience properties to generate list of peers based on their status are provided: peers_in_initial_state, peers_connected, peers_routed, peers_unreachable

Database

The initialization of the store is done using the start_db(), where the database is read (or created) and synced for the first time.

Metadata table is only read once, at start_db() time. If the metadata table(p2p0mq_meta) does not exist, the database is assumed to be new, so create_meta_table() is used to initialize it. Meta-variables stored at that time are:

• uuid: the id of the peer; only a single peer can be stored in a database; if the value is None a new uuid is allocated at this point;
• db_created: the value of the db_created is updated to current time and this value is stored in the database.

If a meta-table exists then all key-value pairs are read and attributes for each are set in the store instance (includes uuid and db_created).

The store merges the content of the p2p0mq_peers table in the database with the memory list of peers from time to time. Peers existing only in memory are saved to the database and peers from the database are constructed and used. The user can add peers to the database and they will be added to the list automatically.

Note that this class does nothing to contact these peers. That is the responsibility of the concerns.

The information stored in the peers table is:

• peer_id: a unique database identifier (p2p0mq.peer.Peer.db_id)
• uuid: a unique zmq identifier for the peer (p2p0mq.peer.Peer.uuid)
• host: the host part of the address (p2p0mq.peer.Peer.host)
• port: the port where we should contact this peer (p2p0mq.peer.Peer.port)

class p2p0mq.peer_store.PeerStore(db_file_path=None, app_uuid=None, *args, **kwargs)

List of peers we know of.

db_file_path

The path of the local sqlite database used for peer persistence, among others.

Type:str

peers

The peers we know of, with keys being the unique identifier of the peer and values being p2p0mq.peer.Peer instances.

Type:dict

peers_lock

Use the peers attribute only after you have acquired this lock.

Type:threading.Lock

next_peer_db_sync_time

time (in seconds since the Epoch) when next database sync should take place.

Type:float

_uuid

Unique identifier of the local peer. Use uuid property to access and change this member.

db_created

The time (in seconds since the Epoch) when the database has been created.

Type:float

add_peer(peer)

Adds a peer from code (database does not call this method).

create_meta_table(c)

Creates the table into the database.

create_peers_table(c)

Creates the table into the database.

start_db()

Called when an app is done with this instance.

sync_database(force=False)

Synchronizes the content of the memory with the database.

table_exists(c, name)

Tells if our table exists in the database.

take_peer(peer)

Removes a peer (database does not call this method).

terminate_db()

Called when an app is done with this instance.

This method should be written defensively, as the environment might not be fully set (an exception in p2p0mq.app.theapp.LocalPeer.create() does not prevent this method from being executed).

uuid

Unique identifier for this peer.