You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #2652 the concept of listeners was removed from the Transport in the sense that having listener streams is not enforced anymore. Instead the transport is responsible for managing its listeners and polling them.
As part of #2652 the relay ClientTransport was adjusted to the trait changes so that now the ClientTransport manages and drives its listener streams. The underlying architecture was not changed and the concept of listeners remains internally.
How it currently works is that:
for each relayed listening address, we create a new Listener stream and drive it for events
communication from the Behaviour to the ClientTransport (necessary for informing the Listener of the result of a reservation and of incoming relayed connections) is done via a channel from the Handler (of the connection to the relay) to the Listener
said channel is created in the ClientTransport, then sent via a channel from transport to behaviour, and then passed from behaviour to the handler.
With the transport changes of #2652, we may be able to reduce the complexity here by removing the listener streams.
The client transport must be aware of the different listeners, but it may not need to drive an extra stream for each listener.
One idea would be to just have one channel between behaviour and transport for each direction and track the necessary states directly in the ClientTransport and Behaviour.
I originally considere to do something like this in #2652, but eventually decided against it because of the reasons described in #2652 (comment).
However, I did not look into it in too much detail, and I think it is still worth exploring. Maybe @mxinden you can also give some input here as the original author of the relay_v2 protocol.
The text was updated successfully, but these errors were encountered:
Maybe @mxinden you can also give some input here as the original author of the relay_v2 protocol.
I am in favor of the above suggestion. That said, I haven't played through it in detail myself, thus I can't comment whether it will turn out to be fruitful.
thomaseizinger
changed the title
protocols/relay: Reconsider listener streams in ClientTransport
relay: remove listener streams in ClientTransportOct 1, 2023
thomaseizinger
changed the title
relay: remove listener streams in ClientTransport
relay: remove listener streams in client::TransportOct 1, 2023
Description
With #2652 the concept of listeners was removed from the
Transport
in the sense that having listener streams is not enforced anymore. Instead the transport is responsible for managing its listeners and polling them.As part of #2652 the relay
ClientTransport
was adjusted to the trait changes so that now theClientTransport
manages and drives its listener streams. The underlying architecture was not changed and the concept of listeners remains internally.How it currently works is that:
Listener
stream and drive it for eventsBehaviour
to theClientTransport
(necessary for informing theListener
of the result of a reservation and of incoming relayed connections) is done via a channel from theHandler
(of the connection to the relay) to theListener
ClientTransport
, then sent via a channel from transport to behaviour, and then passed from behaviour to the handler.With the transport changes of #2652, we may be able to reduce the complexity here by removing the listener streams.
The client transport must be aware of the different listeners, but it may not need to drive an extra stream for each listener.
One idea would be to just have one channel between behaviour and transport for each direction and track the necessary states directly in the
ClientTransport
andBehaviour
.I originally considere to do something like this in #2652, but eventually decided against it because of the reasons described in #2652 (comment).
However, I did not look into it in too much detail, and I think it is still worth exploring. Maybe @mxinden you can also give some input here as the original author of the
relay_v2
protocol.The text was updated successfully, but these errors were encountered: