-
Notifications
You must be signed in to change notification settings - Fork 18
start and stop accepting connections #34
Comments
I feel this belongs to |
@diasdavid The thought crossed my mind. This would have the benefits of being simpler to implement (only one package touched). I would argue that, since there may exist a significant overhead of establishing the raw connection for each transport, it would be beneficial to be able to prevent connections from happening in the first place. I believe this could be mostly significant in the case of webrtc.. |
@pgte good point. So in fact what you want is the ability to stop the listeners and start them back again at a later time. This is possible today from the interface-transport, just needs to be used accordingly in the switch. |
@diasdavid yes, but wouldn't stopping a listener, (at least in some transports), also destroy all the underlying connections? |
It doesn't destroy (or shouldn't) it actually waits for them to close and rejects new ones meanwhile. |
Here, in the websocket-star protocol, it definitely closes the connection to the relay/discovery server: https://github.com/libp2p/js-libp2p-websocket-star/blob/master/src/listener.js#L77-L85 |
Which would, AFAIK, terminate all the underlying relayed connections.. |
@pgte that's a bug then :) |
OK, filed issue here: libp2p/js-libp2p-websocket-star#49 |
Thanks. Also track the work needed on libp2p-switch. |
Also a bug in libp2p-tcp: libp2p/js-libp2p-tcp#92 |
Tracking here: https://github.com/libp2p/js-libp2p-switch/issues/251 |
To allow denying new connections before they're established, the transport interface must expose a way to stop accepting new connections, as well as start accepting them again.
First discussed here.
The proposed API here is adding two methods
.start()
and.stop()
.For backwards compatibility, by default, the transport starts in the "accepts connections" state.
The text was updated successfully, but these errors were encountered: