Recovery of pipeTransport disconnection

[hasnarof]

So now I’m designing the flow of a scenario where multiple servers are used.

streamer client → publisher SFU server → broadcaster SFU server → watcher client

Broadcaster SFU servers can be multiple, and has a relationship of 1 publisher server and many broadcaster servers. I use pipeTransport to connect between publisher server and broadcaster server before the media is transmitted to the watcher client. I’m thinking of the flow of recovery when the pipeTransport is disconnected. I have read other forums regarding pipeTransport disconnection that can only be detected by the ping pong mechanism (link). My questions:

1. What are the cases when pipeTransport is disconnected? Is the case only when the publisher/broadcaster server is down?
2. After we use ping pong and detect that the broadcaster server is down, how can we recover the pipeTransport without the client having to wait for too long? For now, what I can think of is to create a new broadcaster server, create new pipeTransports, and reuse old producer from the publisher server. Is that correct?
3. Ping pong SCTP mechanism using pipeTransport or directTransport?
4. Are there any possibilities to use another method besides ping pong to detect disconnection?

[BronzedBroth]

@hasnarof

Are there any possibilities to use another method besides ping pong to detect disconnection?

Yes, we can utilize MTR and look for Packet Loss if there’s no rate-limiting false positives.

@hasnarof

• Ping pong SCTP mechanism using pipeTransport or directTransport?

No statement we utilize WebSockets all the way through from chat server to brokering server to media servers. Much easier if you asked me.

@hasnarof

After we use ping pong and detect that the broadcaster server is down, how can we recover the pipeTransport without the client having to wait for too long? For now, what I can think of is to create a new broadcaster server, create new pipeTransports, and reuse old producer from the publisher server. Is that correct?

We would re-use what we can. If the viewer server crashes though we need to re-pipe, and all the fun stuff again to a new server.

If the broadcasting server goes down then it’s a full reset for itself and viewer servers connected.

---

@hasnarof

What are the cases when pipeTransport is disconnected? Is the case only when the publisher/broadcaster server is down?

They’ll remain in their current state until told to disconnect. So you will manually manage the Pipes and their contents.

[hasnarof]

Thank you for your response

@BronzedBroth

Yes, we can utilize MTR and look for Packet Loss if there’s no rate-limiting false positives.

Can you elaborate what is MTR?

[BronzedBroth]

MTR is My Traceroute.
https://www.cloudflare.com/learning/network-layer/what-is-mtr/

Give above a read and definitely pay attention to “How to read MTR” as false positives could leave you closing a service when it’s in fact AOK.

I’d run these tests between a few end-points and determine if we’re looking AOK.