Function exp_dial_unordered 

pub fn exp_dial_unordered<M: RemoteMessage>(
    addr: ChannelAddr,
    num_streams: usize,
) -> Result<ChannelTx<M>, ChannelError>

Experimental: dial with out-of-order delivery and N parallel streams.

Opens N TCP connections sharing a single SessionId (distinct stream_id in 1..=num_streams so the server routes them through the multi-stream receive path). Frames are load-balanced across streams via a shared MPMC work queue — idle writers pull next. API may change.

Semantics (how this differs from dial)

Multi-stream trades several of dial’s delivery guarantees for aggregate bandwidth. Use dial when any of these matter:

• Ordering. Messages are delivered to the receiver in arrival order across streams, not send order. Two messages posted back to back on the sender may reach the receiver out of order when they’re carried on different TCP streams. dial is strictly in-order.

• Retransmission on reconnect. If a writer’s TCP connection drops after the bytes of a message have been written but before the peer acks, that message is not retransmitted on the new connection. It may be silently lost. dial re-sends all unacked messages on reconnect.

• Delivery timeouts. No delivery timeout is enforced. On sustained peer outage, writers reconnect indefinitely (backoff capped at 5s); senders block in send().await with no bound. dial fails unacked sends after MESSAGE_DELIVERY_TIMEOUT.

• Tx::send return semantics. On session shutdown, messages still in the unacked buffer have their return_channel dropped. Per the Tx::send contract, this makes send().await return Ok(()) for messages that may never have been delivered — i.e. a “success” return does not actually confirm delivery here. dial delivers a structured SendError instead.

Ack semantics

Receivers ack a cumulative watermark: the highest N such that all of 0..=N have been observed across all streams. Acks may stall behind a single missing seq on a slow stream.