Développement WebRTC et peer-to-peer
Nous construisons des systèmes en temps réel et peer-to-peer : connecter deux machines directement à travers des réseaux hostiles, maintenir une latence assez faible pour l'interaction en direct, et basculer sur un relais authentifié lorsqu'un chemin direct ne peut pas être établi.
Ce que temps réel et peer-to-peer signifient ici
Connecter deux appareils directement est plus difficile qu'il n'y paraît : la plupart se trouvent derrière des NAT et des pare-feu qui refusent le trafic non sollicité. Nous construisons tout le chemin : la traversée de NAT, la coordination qui l'établit, et un relais authentifié pour les cas où une connexion directe est impossible.
- Connexions peer-to-peer directes à travers NAT et pare-feu
- La coordination des sessions : qui se connecte à qui, et quand
- Un relais authentifié en repli pour les réseaux restrictifs
- Un transport chiffré entre pairs, avec identité vérifiée
- Des canaux audio, vidéo et de données à faible latence
- Un débit adaptatif qui réagit aux conditions réseau en direct
Notre façon de construire des systèmes temps réel
Nous concevons pour le réseau que vous avez réellement, et non pour celui du schéma. Ce réseau perd des paquets, il est asymétrique et plein de middleboxes. Chaque couche est mesurée en conditions réelles.
- 1
Modèle de connectivité
Nous relevons les conditions réelles de votre réseau (classes de NAT, pare-feu, part des utilisateurs qui auront besoin d'un relais) et concevons la stratégie de connexion en conséquence.
- 2
Coordination et transport
Un service de signalisation coordonne les pairs ; le transport est chiffré et l'identité vérifiée, avec un relais authentifié en repli.
- 3
Pipeline média
Là où du média en direct entre en jeu, un encodage et un décodage qui adaptent la qualité à la bande passante et à la latence de la liaison.
- 4
Tests de résilience
Nous testons sur les classes de NAT courantes et sur des liaisons dégradées, en confirmant que le relais de repli s'engage proprement lorsqu'un chemin direct échoue.
- 5
Exploiter et observer
Des métriques sur le succès des connexions, le taux de repli et la qualité du flux, pour que vous voyiez comment le système se comporte sur le terrain, et pas seulement en laboratoire.
Ce que vous recevez
Une couche de connectivité qui fonctionne sur l'internet réel, avec l'observabilité pour le prouver et la documentation pour se l'approprier.
- Une couche de connexion peer-to-peer avec traversée de NAT et relais en repli
- Un service de signalisation pour la coordination des sessions et des pairs
- Un transport chiffré entre pairs, avec identité vérifiée
- Un chemin média à débit adaptatif, là où de l'audio/vidéo en direct est nécessaire
- Des métriques de succès de connexion et de taux de repli intégrées
- Une documentation d'architecture et une passation pour votre équipe
Comment nous construisons la couche de connectivité
Nous concevons la couche de connectivité selon les conditions réelles de votre réseau : en direct partout où le réseau le permet, sinon via un relais authentifié. Chaque session est chiffrée, chaque identité vérifiée.
Questions sur le temps réel et le P2P
Toutes les connexions passent-elles en peer-to-peer ?
La plupart, oui, mais tous les réseaux n'autorisent pas un chemin direct. Une conception fiable se connecte en direct partout où le réseau le permet, et sinon via un relais authentifié. La connexion tient ainsi même quand le vrai peer-to-peer est impossible.
Est-ce la même chose que d'utiliser un service WebRTC hébergé ?
WebRTC est un ensemble de briques de base ; un service hébergé les enveloppe avec la signalisation, les relais et la tarification de quelqu'un d'autre. Nous pouvons construire sur WebRTC là où il convient, ou implémenter la couche de connectivité directement quand vous avez besoin de contrôle sur le transport, le relais et les flux de données. Nous recommanderons ce qui sert le mieux vos besoins de latence, de coût et de résidence des données.
Comment sécurisez-vous les connexions entre pairs ?
Le transport est chiffré et l'identité vérifiée : les pairs savent exactement à qui ils parlent avant que la moindre donnée circule, et un attaquant en position d'homme du milieu ne peut pas s'insérer discrètement. Quand un relais est utilisé, il est authentifié ; ce n'est pas un tuyau ouvert.
Pouvez-vous garder le média fluide sur une mauvaise connexion ?
Oui. Nous construisons une échelle de débit adaptative qui réagit à la bande passante et au temps d'aller-retour en direct, ne sacrifiant le détail à la fluidité que lorsqu'elle y est contrainte. Le flux choisit le codec et le débit adaptés à la liaison en temps réel.