Using request-response with large payloads (hundreds of MB) — chunking strategies and ACK latency

[cyrus937]

Hi everyone,

I’m currently working on a libp2p (Rust) application where I need to transfer relatively large application-level messages (up to ~500 MB) between two peers.

At the moment, I’m using:

• TCP + yamux
• the request-response behaviour
• custom codec with explicit chunking (splitting the payload into multiple chunks before sending)

The motivation for sticking with request-response is that it fits well with my application-level semantics (explicit request, explicit response/ACK, timeouts, peer targeting).

One hard requirement I currently have is the following:

I would like to be able to send a request and receive an ACK within ~30 seconds, even when the total payload size is several hundreds of MB.

With my current implementation, even with chunking, I’m observing that:

• each chunk is still sent over a dedicated substream
• the response/ACK for a chunk is only emitted once the full chunk has been received
• this causes the effective ACK latency to scale with payload size, often exceeding my 30s constraint

I understand that request-response implements a strict 1-request–1-response model and does not support streaming responses. I also understand that, for large data transfers, the usual recommendation is to use a dedicated streaming protocol.

That said, I’d like to better understand what is realistically achievable within the constraints of request-response:

1. Are there known patterns for using request-response with chunked payloads while keeping ACK latency under control (e.g. below ~30s)?

• pipelining multiple requests
• cumulative or grouped ACKs
• very small chunk sizes (≤ 1–2 MB)

2. Are there internal behaviours (buffering, backpressure, Yamux interaction, substream lifecycle) that fundamentally limit how fast an ACK can be produced when transferring large payloads this way?

3. From the maintainers’ perspective:
   Is there a hard architectural reason why meeting such an ACK latency constraint is fundamentally incompatible with request-response, even with careful chunking and pipelining?

I’m not opposed to moving to a streaming protocol if necessary, but before doing so I’d like to clearly understand the design boundaries of request-response and whether this use case is fundamentally misaligned with it or simply requires a different usage pattern.

Any insights, pointers, or examples would be greatly appreciated.

Thanks a lot for your time and for the work on rust-libp2p!

[drHuangMHT]

Hi! Consider this code from request-response:

rust-libp2p/protocols/request-response/src/handler.rs

Lines 188 to 199 in 5e3519f

	let send = async move {
	let write = codec.write_request(&protocol, &mut stream, message.request);
	write.await?;
	stream.close().await?;
	let read = codec.read_response(&protocol, &mut stream);
	let response = read.await?;
	Ok(Event::Response {
	request_id,
	response,
	})
	};

which means, the response is read after the request has been written(sent) completely. For very large requests, depending on the bandwidth between peers, it can take tens of seconds to complete. The same is for the receiving end where the response is written after the request has been read completely:

rust-libp2p/protocols/request-response/src/handler.rs

Lines 136 to 159 in 5e3519f

	let recv = async move {
	// A channel for notifying the inbound upgrade when the
	// response is sent.
	let (rs_send, rs_recv) = oneshot::channel();
	let read = codec.read_request(&protocol, &mut stream);
	let request = read.await?;
	sender
	.send((request_id, request, rs_send))
	.await
	.expect("`ConnectionHandler` owns both ends of the channel");
	drop(sender);
	if let Ok(response) = rs_recv.await {
	let write = codec.write_response(&protocol, &mut stream, response);
	write.await?;
	stream.close().await?;
	Ok(Event::ResponseSent(request_id))
	} else {
	stream.close().await?;
	Ok(Event::ResponseOmission(request_id))
	}
	};

The most straightforward way of solving this is by chunking your request to a smaller size, for example a few MB as you mentioned.
For streaming large amount of data, consider using libp2p-stream. You can compose request-response together with stream as one single NetworkBehaviour, and track requests, responses, streaming progress, etc there. Use request-response for control message exchange, and let stream do the heavy-lifting. You may use two kinds of ACK message, one for "the request has been received and the transfer has started", and another for "transfer completed", the former should come much quicker than the latter.