transports/tcp: use futures::stream::SelectAll
for driving listener streams
#2781
Labels
futures::stream::SelectAll
for driving listener streams
#2781
Description
With #2652 polling the listeners of a transport became the transport's responsibility.
We currently do this in
TcpTransport::poll
analogous to how it was done before in the swarmListenerStream
: by iterating through the list ofTcpListenStream
s and sequentially polling each listener for an event, returning the first event from a listener.Instead of doing this manual iteration, we should use
futures::stream::SelectAll
for polling allTcpListenStream
s. This is already used in e.g. the relayClientTransport
and thewasm_ext::ExtTransport
.The following changes would be required:
TcpListenerEvent
, instead<TcpListenStream as Stream>::Item
should directly return aTransportEvent
.<TcpListenStream as Stream>::poll_next
should returnPoll::Ready(None)
for this listener so that theSelectAll
combinator drops the streamTcpListenStream
s in aSelectAll
, poll theSelectAll
stream inTcpTransport::poll
.Motivation
SelectAll
is much more efficient when driving multiple streams since it only polls its inner streams when they generate notifications.Apart from that, it reduces the complexity as we only have to poll the
SelectAll
stream rather than then manual iteration and polling.Current Implementation
The
TcpListenStream
s are pinned in aVecDeque
. When the task is woken andTcpTransport::poll
called, we iterate through this list by popping the first element, polling it for new events, pushing the listener back onto the list. If the listener returned anTcpListenerEvent
we return andTransportEvent
for it, else the next listener is polled:rust-libp2p/transports/tcp/src/lib.rs
Lines 509 to 582 in eaf3f3a
Are you planning to do it yourself in a pull request?
No (or at least not in the near future).
The text was updated successfully, but these errors were encountered: