How should we go about merging major changes into the codebase #6652
alexpyattaev
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Reasoning
We have two relatively big changes coming to the validator:
Both of these can be expected to be fairly intrusive and not obviously backwards compatible.
Question
Which transition policy do we adopt for solana crates?
Scope of the problem: Multihoming
Non-exhaustive list of things that will have to be changed:
gossip-host
Sockets
Detailed Changes
Gossip
NodeConfig
gossip_addr
SocketAddr
advertised_ip
IpAddr
gossip_port
u16
bind_ip_addr
IpAddr
bind_ip_addrs
BindIpAddrs
NodeConfig
refactor includinggossip_addr
removal andadvertised_ip
,gossip_port
addition was merged intomaster
: RefactorNodeConfig
to improve clarity #6553bind_ip_addr: IpAddr
->bind_ip_addrs: BindIpAddrs
PR: Multihoming: add multiple bind addresses. #6522Sockets
gossip
UdpSocket
Multihomed<AtomicUdpSocket>
tvu
Vec<UdpSocket>
Multihomed<UdpSocket>
retransmit_socket
Vec<UdpSocket>
Multihomed<AtomicUdpSocket>
repair
UdpSocket
Multihomed<AtomicUdpSocket>
serve_repair
UdpSocket
Multihomed<UdpSocket>
TVU
TvuSockets
fetch
Vec<UdpSocket>
Multihomed<UdpSocket>
Vec<UdpSocket>
, but I want to make it clear we are binding on multiple interfacesretransmit
Vec<UdpSocket>
Multihomed<AtomicUdpSocket>
repair
UdpSocket
Multihomed<AtomicUdpSocket>
ancestor_hashes_requests
UdpSocket
Multihomed<UdpSocket>
Vec<UdpSocket>
, but I want to make it clear we are binding on multiple interfacesancestor_hashes_requests_client
UdpSocket
Multihomed<AtomicUdpSocket>
Tvu::new(...)
TvuSockets
TvuSockets
TvuSockets
as defined aboveRetransmitStage::new(...)
retransmit_sockets
Arc<Vec<UdpSocket>>
Arc<Multihomed<AtomicUdpSocket>>
Repair Client
ShredFetchStage::new(...)
repair_socket
Arc<UdpSocket>
Arc<Multihomed<AtomicUdpSocket>>
WindowService::new(...)
repair_socket
Arc<UdpSocket>
Arc<Multihomed<AtomicUdpSocket>>
RepairService::new(...)
repair_socket
Arc<UdpSocket>
Arc<Multihomed<AtomicUdpSocket>>
Repair Server
ServeRepairService::(...)
repair_socket
UdpSocket
Multihomed<UdpSocket>
AncestorHashesService
Uses the same UDP socket for sending/receiving. This will get updated so that we bind to all interfaces on ingress but then use a hotswappable socket on egress.
WindowService::new(...)
ancestor_hashes_socket
Arc<UdpSocket>
Arc<Multihomed<UdpSocket>>
ancestor_hashes_socket_client
Arc<Multihomed<AtomicUdpSocket>>
RepairService::new(...)
ancestor_hashes_socket
Arc<UdpSocket>
Arc<Multihomed<UdpSocket>>
ancestor_hashes_socket_client
Arc<Multihomed<AtomicUdpSocket>>
AncestorHashesService::new(...)
ancestor_hashes_request_socket
Arc<UdpSocket>
Arc<Multihomed<UdpSocket>>
ancestor_hashes_request_socket_client
Arc<Multihomed<AtomicUdpSocket>>
TPU
TpuSockets
transactions
Vec<UdpSocket>
Multihomed<UdpSocket>
Vec<UdpSocket>
, but I want to make it clear we are binding on multiple interfacestransaction_forwards
Vec<UdpSocket>
Multihomed<UdpSocket>
Vec<UdpSocket>
, but I want to make it clear we are binding on multiple interfacesvote
Vec<UdpSocket>
Multihomed<UdpSocket>
Vec<UdpSocket>
, but I want to make it clear we are binding on multiple interfacesbroadcast
Vec<UdpSocket>
Multihomed<AtomicUdpSocket>
transactions_quic
Vec<UdpSocket>
transactions_forwards_quic
Vec<UdpSocket>
vote_quic
Vec<UdpSocket>
vote_forwarding_client
UdpClient
TPU UDP Ingress
Bind to all interfaces on ingress. Besides
TvuSockets
update, all functions can remain the sameBroadcastStage
BroadcastStage::new(...)
sock
Arc<Vec<UdpSocket>>
Arc<Multihomed<AtomicUdpSocket>>
broadcast_shreds(...)
s
&UdpSocket
&AtomicUdpSocket
TPU Streamer
Uses
TpuSockets::transactions_quic
Have to take a different approach here. We cannot hotswap QUIC Endpoints like we can with
UdpSocket
sspawn_server_multi(...)
streamer/src/quic.rs
spawn_server_multi(...)
streamer/src/nonblocking/quic.rs
Streamer
Need to support hotswapping sockets. We can pretty easily avoid breaking the public api. We just need to define two new functions along side the current
streamer::receiver()
andstreamer::responder()
streamer::receiver(...)
Create a new function called
streamer::receiver_atomic(...)
-> wrapper aroundrecv_loop(...)
GossipService
andRepair
switched over to newreceiver_atomic(...)
, we can get rid ofreceiver(...)
streamer::responder(...)
Create a new function called
streamer::responder_atomic(...)
-> wrapper aroundresponder_loop(...)
GossipService
andRepair
switched over to newresponder_atomic(...)
, we can get rid ofresponder(...)
CLI Args
--bind-address
Update
--bind-address
to accept multiple arguments. First--bind-address
is primary. Following ones are backups--gossip-host
Deprecate
--gossip-host
in favor of--bind-address
. This removes a validator operator's ability to run a node behind a NAT, but will avoid confusion when starting a validator. We don't need the bind address to be different than the IP advertised to the cluster over gossip.NOTE: already merged into master for v3.0 release
AdminRpc
AdminRpcRequestMetadataPostInit
sockets
Option<Arc<Sockets>>
Sockets
that stores all of the socket bindings and referenced in the validator asnode.sockets
Scope of the problem: Alpenglow
Non-exhaustive list of things that will have to be changed:
Beta Was this translation helpful? Give feedback.
All reactions