update docs for tpu using Quic (#34721)
Update tpu doc on using QUIC about streams and throttling
This commit is contained in:
parent
74df203dd4
commit
843854409e
|
@ -9,12 +9,22 @@ responsible for block production.
|
|||
|
||||
![TPU Block Diagram](/img/tpu.svg)
|
||||
|
||||
Transactions encoded and sent in UDP packets flow into the validator
|
||||
Transactions are encoded and sent in QUIC streams into the validator
|
||||
from clients (other validators/users of the network) as follows:
|
||||
|
||||
* fetch stage: allocates packet memory and reads the packet data from
|
||||
the network socket and applies some coalescing of packets received at
|
||||
the same time.
|
||||
* The quic streamer: allocates packet memory and reads the packet data from
|
||||
the QUIC endpoint and applies some coalescing of packets received at
|
||||
the same time. Each stream is used to transmit a packet. And there is limit on the
|
||||
maximum of QUIC connections can be concurrently established between a client
|
||||
identified by (IP Address, Node Pubkey) and the server. And there is a limit on the
|
||||
maximum streams can be concurrently opened per connection based on the sender's
|
||||
stake. Clients with higher stakes will be allowed to open more streams within
|
||||
a maximum limit. The system also does rate limiting on the packets per
|
||||
second(PPS) and applied the limit to the connection based on the stake.
|
||||
Higher stakes offers better bandwidth. If the transfer rate is exceeded,
|
||||
the server can drop the stream with the error code (15 -- STREAM_STOP_CODE_THROTTLING).
|
||||
The client is expected to do some sort of exponential back off in retrying the
|
||||
transactionswhen running into this situation.
|
||||
|
||||
* sigverify stage: deduplicates packets and applies some load-shedding
|
||||
to remove excessive packets before then filtering packets with invalid
|
||||
|
|
Loading…
Reference in New Issue