We have properties like ‘paused’ in Consumers and Producers, but why there is no property like ‘connected’ in Transport class to bypass thrown errors if ‘connect’ method called during connection process or second time after the transport has been connected?
The ‘connected’ state might not be as straightforward to determine as in other contexts. The connection process involves multiple events, callbacks, and states like ICE gathering, DTLS handshake, and more. Determining whether a connection is fully ‘connected’ or not can be nuanced.
To assist a bit, try monitoring such
- ICE Connection State (Client Side)
- Signaling events for the user closing their connection
- Heartbeat mechanism (if user doesn’t respond to second heartbeat request)
- Media Stream State for zero data transmission x amount of time
- Timeouts if a user can connect to DTLS within certain amount of time to free up queue lines/etc.
- Some server side monitoring.
1 Like
AFAIU he talks about transport.connect() having being already called, just that.
It may make sense that there is a transport.connected property. As a workaround you can store it in transport.appData.
1 Like
If the transport.connected property is based on internal events, there could be race conditions where the property does not accurately represent the true connection state at all times.
In other words we’d need the server to tell the client what’s up still, so leaving it server logic is ideal at least for me. If there is a way though that’d be neat, I’ve explored slightly.
1 Like
Definitely you insist as if transport.connect() resolved once ICE + DTLS + everything else is connected, but that’s not what transport.connect() method does, so we are not talking about the same.
2 Likes
I understand your perspective, and I agree that there might be a misunderstanding. I want to clarify that I don’t mean to imply that transport.connect() itself resolves once ICE, DTLS, and other aspects are completely connected. Rather, what I’m highlighting is that the notion of the client/server’s perceived ‘connected’ state doesn’t always guarantee a reliable and accurate representation of the underlying connections.
The state of being ‘connected’ that we often rely on can sometimes be misleading due to potential inaccuracies or underlying complexities. This can potentially lead to code issues or unexpected behavior. It’s important to consider these nuances and perhaps incorporate additional checks or validations to ensure a more robust handling of the connection status.
In essence, while transport.connect() might not directly handle the complete connection process, addressing potential inaccuracies in the perceived state of connection is crucial to ensure the reliability and stability of our code.
Well, it’s up to the topic creator to confirm what he meant. IMHO he just asked for a connected getter telling whether transport.connect() was already called before.
1 Like
You are right - I am just asking about ‘connected’ when it’s started to process after connect() method called and it’s definitely NOT disconnected, so the second call to connect() won’t fail.
If you are using a transport from several places, then failing connect() is not enough, you’ll need to wait until the transport is connected anyway. Instead of checking some flag, keep the Promise that Transport.connect() returns along with the transport and wait for it if it is already exists.