At the moment the peer_service_manager will open and maintain one connection in each direction, that is when node A connects to node B it does not take into account that maybe B already established a connection to A.
More specifically, the peer_service_manager will check the current outgoing connections i.e. partisan_peer_service_client (in v4 from its in-process state cache and in v5 using partisan_peer_service_connections which uses ets) without considering the existing incoming connections partisan_peer_service_server.
The above is contrary to what disterl does, which ensures there is always one TPC connection between two nodes. disterl does this during the handshake checking the existing connections (or in-flight connection attempts).
For Partisan, we can do the same but taking into account Channel Parallelism.
At the moment the peer_service_manager will open and maintain one connection in each direction, that is when node A connects to node B it does not take into account that maybe B already established a connection to A.
More specifically, the peer_service_manager will check the current outgoing connections i.e.
partisan_peer_service_client(in v4 from its in-process state cache and in v5 usingpartisan_peer_service_connectionswhich usesets) without considering the existing incoming connectionspartisan_peer_service_server.The above is contrary to what
disterldoes, which ensures there is always one TPC connection between two nodes.disterldoes this during the handshake checking the existing connections (or in-flight connection attempts).For Partisan, we can do the same but taking into account Channel Parallelism.