TPU client connections should be keyed by socket address instead of public key

[buffalu]

Problem

There is an increasing number of validators which share the same QUIC server (IP:port) for the same connection (BAM, Harmonic, and others).

However, several pieces of TPU-related code in the validator client do take this into account. Several versions of TPU code floating around key connections based on the public key.

When connections are keyed by public key instead of socket address, the same validator client can establish multiple connections to the same QUIC server. If the QUIC server isn't customized to handle this, there ends up being multiple duplicate connections and potential connection thrashing. This can lead to challenges sending transactions from clients that don't handle this properly.

Proposed Solution

• All TPU related code should key connections and maintain connection caches keyed by SocketAddr instead of Pubkey. It should assume there are multiple validators behind a shared TPU.
• When sending transactions, a public key -> tpu address transformation should be done (using contact info from gossip). It should then find the correct connection to send it. If one doesn't exist, it should establish that connection.

[KirillLykov]

In the streamer staked connections are identified by Pubkey and unstaked by IP.
In the tpu-client-next, we use IPs to identify connections.
Why so -- because it is a little bit harder to generate many IPs than many Pubkeys which limits the spammer activity.

[KirillLykov]

Is this still an issue? Btw Triton might use different approach to identify the connection (based on Pubkey), I haven't checked their implementation on that issue.

[buffalu]

Is this still an issue? Btw Triton might use different approach to identify the connection (based on Pubkey), I haven't checked their implementation on that issue.

alex on our team created two issues to help fix their problems:

• Bound retry attempts on dropped connections rpcpool/yellowstone-jet#123
• Cache connections by IP, not pubkey rpcpool/yellowstone-jet#122

[KirillLykov]

@buffalu but do we need to do something on streamer/tpu-client-next? It seems that all the issues are related to the yellowstone, so maybe close this issue?