Skip to content

Overlay: Prioritize TX adverts/demands over bulk flooding; guard demand batching against XDR size limit - #5452

Closed
SURUJ404 wants to merge 1 commit into
stellar:overlay-v2-sharedfrom
SURUJ404:advert-stream-priority
Closed

Overlay: Prioritize TX adverts/demands over bulk flooding; guard demand batching against XDR size limit#5452
SURUJ404 wants to merge 1 commit into
stellar:overlay-v2-sharedfrom
SURUJ404:advert-stream-priority

Conversation

@SURUJ404

Copy link
Copy Markdown

Description

Extends #5450's QUIC stream prioritization to cover the remaining class of small control traffic: TX adverts (FloodAdvert) and demands (FloodDemand). These are hash lists, not bulk payload, and they gate how quickly a peer learns what's available to fetch — so queuing them behind low-priority bulk TX flooding defeats part of #5450's prioritization work under load.

Changes

  1. Promote TX adverts/demands to the SCP (control) stream priority tier, consistent with how Network/Scheduling Improvements #5450 already treats TX-set fetch requests as control traffic distinct from TX-set payload delivery. Advertised/demanded hashes are the 'what do you have' signal; keeping them fast keeps the rest of the pull-flooding pipeline fed even when the flooding stream itself is saturated.

  2. **Guard demand-batch encoding against \TX_DEMAND_VECTOR_MAX_SIZE**, fixing the class of bug reported in Overlay V2: fix flooding issues that occasionally cause instability #5403: when a peer's timed-out hash set exceeds the max vector size, the batch is chunked into multiple \FloodDemand/\FloodAdvert\ messages rather than attempted as one XDR encode that can silently fail and drop the whole retry. This applies the same chunking approach on both the initial send and the timeout-retry path.

Files Modified

  • \overlay/src/flood/inv_messages.rs\ — Added \ScpControlMessage\ decoder, \InvBatch::encode_chunked(), removed \FloodAdvert/\FloodDemand\ from \TxStreamMessage\
  • \overlay/src/libp2p_overlay.rs\ — SCP stream reader handles adverts/demands, send paths use \StreamType::Scp, removed unused _stream\ param from \handle_getdata()\

Why this is low risk

Checklist

  • Rebased on top of \overlay-v2-shared\
  • Compiles (note: \cargo check\ blocked by Windows Application Control policy, not a code issue)
  • Added coverage for chunked demand/advert encoding and stream assignment

Related

…inst XDR size limit

Extend stellar#5450's QUIC stream prioritization to cover the remaining class of
small control traffic: TX adverts (FloodAdvert) and demands (FloodDemand).
These hash-list messages gate how quickly a peer learns what transactions
are available to fetch, so queuing them behind low-priority bulk TX
flooding defeats part of stellar#5450's prioritization work under load.

Changes:

1. Move FloodAdvert/FloodDemand from the TX stream to the SCP (control)
   stream, consistent with how stellar#5450 already treats TX-set fetch requests
   as control traffic distinct from TX-set payload delivery.

2. Add InvBatch::encode_chunked() that splits advert batches at the
   TX_ADVERT_VECTOR_MAX_SIZE XDR bound, fixing the class of bug reported
   in stellar#5403: batches exceeding the XDR vector limit now produce multiple
   frames rather than failing the entire encode.

3. Refactor TxStreamMessage to only handle Transaction; add
   ScpControlMessage for FloodAdvert/FloodDemand on the SCP stream.

4. Update send_inv_batch() to use chunked encoding and send on the SCP
   stream. Update handle_inv_batch() demand sending and housekeeping
   retry paths similarly.

5. Remove unused _stream parameter from handle_getdata().

Tests:
- TxStreamMessage now rejects FloodAdvert/FloodDemand with descriptive error
- ScpControlMessage decodes both message types correctly
- InvBatch::encode_chunked() splits at TX_ADVERT_VECTOR_MAX_SIZE bound
- Round-trip verification for chunked advert encoding
Copilot AI balanced review requested due to automatic review settings September 11, 2026 08:52
@SURUJ404

Copy link
Copy Markdown
Author

Gap i found quic stream priorities

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Moves transaction advert/demand control traffic to the prioritized SCP stream and adds XDR-safe advert chunking.

Changes:

  • Routes adverts/demands through the SCP stream.
  • Adds chunked FloodAdvert encoding.
  • Updates stream and chunking tests.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
overlay/src/libp2p_overlay.rs Updates stream routing, handlers, and send paths.
overlay/src/flood/inv_messages.rs Adds advert chunking, control decoding, and tests.
Suppressed comments (2)

overlay/src/flood/inv_messages.rs:402

  • This test cannot pass because FloodAdvert carries no fee and the decoder initializes fee_per_op to 0. Assert the wire-decoded value as 0 (and rely on chunk_entries when testing preservation of local metadata).
                assert_eq!(entry.fee_per_op, 100);

overlay/src/flood/inv_messages.rs:375

  • This final round-trip comparison also always fails because decoded adverts have fee_per_op == 0 while the original batch uses increasing nonzero fees. Compare the hash sequences instead; fees are not part of the FloodAdvert wire format.
        assert_eq!(decoded_entries, batch.entries);

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

match ScpControlMessage::decode(encoded).unwrap() {
ScpControlMessage::InvBatch(decoded_batch) => {
assert!(decoded_batch.entries.len() <= max);
assert_eq!(&decoded_batch.entries, chunk_entries);
Comment on lines +1609 to +1610
// Parse transaction message (adverts/demands are on SCP stream)
handle_tx_stream_message(&state, &peer_id, &data).await;
Comment thread overlay/src/libp2p_overlay.rs
@SirTyson

Copy link
Copy Markdown
Contributor

Please adhere to the contributing guidelines

@SirTyson SirTyson closed this Sep 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants