Function dial 

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

Dial with out-of-order delivery and N parallel streams.

Opens N links 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.

Semantics (how this differs from super::dial)

Multi-stream trades several of super::dial’s delivery guarantees for aggregate bandwidth. Use super::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 streams. super::dial is strictly in-order.

• Retransmission on reconnect. If a writer’s 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. super::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. super::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. super::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.