A playground to make WebRTC easier to deploy, safer and more robust

  • By Pion
  • Last update: Apr 12, 2023
  • Comments: 2

webrtc-zero-downtime-restart

webrtc-zero-downtime-restart is a simple Pion WebRTC broadcast server that can be restarted without disconnecting users. All the WebRTC state is suspended to disk. The next time the process is started that information is read into memory. All the remote PeerConnections will be unaware that they are even connected to a new process. This gives us the following benefits.

Painless Deploys

No more migrating users to a new process when you want to deploy code. At anytime you can replace the binary you are running and no users will be impacted. You don't need to implement extra signaling/error handling for your deploy process.

Easier Scaling

Move clients to an entirely different host without them knowing. You can do this with zero interruption in service or additional signaling.

Greater Resiliency

Since server state is constantly being written to disk you don't need to worry about crashes anymore. If you server goes down (and then restarts) it will automatically resume the last known good state.

Running

Execute go run github.com/Sean-Der/webrtc-zero-downtime-restart@latest.

This will start the server. On startup the server will print.

Open http://localhost:8080 to access this demo

You can then access it at http://localhost:8080. The first user to connect will broadcast their webcam. Every user after can watch the broadcasted video.

At anytime you can start+stop the process in your terminal. Users will not be disconnected and will be able to continue talking when the process is started again.

What is next

This demo uses reflection to access internal Pion WebRTC APIs. We will be working on designing the final APIs for the next major release of Pion WebRTC. We would love your feedback ideas either on the repo or Slack

Download

webrtc-zero-downtime-restart.zip

Comments(2)

  • 1

    Configure Renovate

    Mend Renovate

    Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

    🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

    Detected Package Files

    • go.mod (gomod)

    Configuration Summary

    Based on the default config's presets, Renovate will:

    • Start dependency updates only once this onboarding PR is merged
    • Enable Renovate Dependency Dashboard creation.
    • Use semantic commit type fix for dependencies and chore for all others if semantic commits are in use.
    • Ignore node_modules, bower_components, vendor and various test/tests directories.
    • Group known monorepo packages together.
    • Use curated list of recommended non-monorepo package groupings.
    • Apply crowd-sourced package replacement rules.
    • Apply crowd-sourced workarounds for known problems with packages.
    • Disable Renovate Dependency Dashboard creation.

    🔡 Would you like to change the way Renovate is upgrading your dependencies? Simply edit the renovate.json in this branch with your custom config and the list of Pull Requests in the "What to Expect" section below will be updated the next time Renovate runs.

    What to Expect

    With your current configuration, Renovate will create 2 Pull Requests:

    Update module github.com/pion/ice/v2 to v2.3.2
    • Schedule: ["at any time"]
    • Branch name: renovate/github.com-pion-ice-v2-2.x
    • Merge into: master
    • Upgrade github.com/pion/ice/v2 to v2.3.2
    Update module github.com/pion/webrtc/v3 to v3.1.59
    • Schedule: ["at any time"]
    • Branch name: renovate/github.com-pion-webrtc-v3-3.x
    • Merge into: master
    • Upgrade github.com/pion/webrtc/v3 to 486f6a2cac5b2e5e4515200a1cdb7d0966097bfc

    ❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.

    This PR has been generated by Mend Renovate. View repository job log here.

  • 2

    Breaks forward privacy

    If I read this code correctly, it is persisting the whole dtls.State. If I understand this correctly, the it is persistig the session key, which breaks forward secrecy.

    Would it not be better to just persist the certificate, and renegotiate at reconnect? This would cost just one round-trip, without breaking forward secrecy.

    At any rate, I recommend having this idea reviewed by a competent cryptographer.

Popular Tag

Related