Comment créer une application Web de chat vidéo aléatoire avec Webrtc, Websocket et Django.

Au cours de ma deuxième année d'université, mon ami et moi avions l'habitude de passer des heures sur Omegle, à discuter avec des personnes aléatoires du monde entier. C’était toujours un mélange de plaisir et de surprise – on ne savait jamais qui on allait rencontrer ensuite. Lorsque Omegle a fermé ses portes, il a laissé un vide. L’excitation de ces connexions aléatoires nous a manqué, et c’est à ce moment-là que je me suis dit : « Pourquoi ne pas en créer ma propre version ? »

Dans ce blog, je vais détailler le processus de conception et de construction d'une telle plate-forme à l'aide de WebRTC et WebSockets, en soulignant les défis auxquels j'ai été confronté et comment je les ai surmontés. À la fin de ce blog, vous comprendrez non seulement comment cela fonctionne, mais vous disposerez également d'une base solide pour commencer à créer votre propre application de communication en temps réel

Je travaille actuellement sur un projet appelé Noto Chats, qui inclut cette fonctionnalité de chat vidéo aléatoire ainsi que plusieurs autres fonctionnalités intéressantes. Le système a été minutieusement testé et fonctionne de manière transparente.

Voici le lien de code pour l'application de chat ramdomvideo https://github.com/Arsh910/RandomVideo-Chat-app

La pile technologique

Frontend : ReactJS pour créer une interface utilisateur interactive.
Backend : canaux Django pour gérer les connexions WebSocket.
Protocole de signalisation : WebSockets pour établir des connexions WebRTC.
Media Streaming : WebRTC pour la communication vidéo et audio peer-to-peer.

Conception

Les pairs des deux côtés essaieront de se connecter, celui qui établira le premier procédera

Composants de la conception :

Si vous n'êtes pas familier avec le fonctionnement de WebRTC, regardez cette vidéo où j'ai appris. Voici un bref aperçu des composants

1. Cliente 1 et Cliente 2
Ceux-ci représentent les deux utilisateurs essayant de se connecter. Chaque client est responsable de créer des offres, de les envoyer au serveur et de répondre aux offres qu'il reçoit.

Analogie : considérez le Client 1 et le Client 2 comme deux personnes qui souhaitent avoir une conversation. Ils ne se connaissent pas encore mais ont hâte de discuter. Chacun prend l'initiative de tendre la main et attend que l'autre réponde.

2. Serveur
Le serveur agit comme un entremetteur. Il ne gère pas la conversation proprement dite mais facilite l'introduction en transmettant les offres et les réponses entre les clients et en aidant à échanger les détails de connexion.

Analogie : Imaginez un ami commun présentant deux personnes lors d’une fête. L’ami ne se joint pas à leur conversation mais s’assure qu’ils connaissent les noms et numéros de chacun pour commencer à parler.

3. Connexion entre pairs
Le PeerConnection est le mécanisme qui établit le lien direct entre les deux clients. Il gère les échanges de médias (audio/vidéo) et assure la stabilité de la connexion une fois établie. Comme peer1 et peer 2 dans l'image ci-dessus.

Analogie : PeerConnection est comme un tunnel sécurisé et privé entre deux maisons. Une fois le tunnel construit, les personnes à l'intérieur peuvent passer des notes, parler ou même envoyer des colis sans que personne d'autre ne le voie.

4. Candidats ICE
Les candidats ICE (Interactive Connectivity establishment) sont les éléments constitutifs de la connexion directe. Ce sont les routes et les chemins de réseau que PeerConnection essaie d'utiliser pour établir la meilleure connexion.

Analogie : les candidats ICE sont comme des cartes montrant plusieurs routes pour relier deux maisons. La connexion trouve la meilleure route (la plus courte, la plus lisse) et l'utilise pour garantir un itinéraire rapide et fiable.

5. Offre et réponse
Le processus de connexion commence par un client (appelant) créant une offre et l'envoyant à l'autre client via le serveur. Le deuxième client (récepteur) crée une réponse et la renvoie. Cet échange établit la connexion.

Analogie : Imaginez une personne envoyant une lettre disant : « Soyons amis ! » L’autre personne répond : « Bien sûr, j’aimerais ça aussi ! » Une fois qu'ils sont d'accord, l'amitié commence.

6. Pistes (flux audio/vidéo)
Les pistes font référence aux flux multimédias (audio et vidéo) qui sont partagés entre les clients une fois la connexion établie.

Analogie : les pistes sont comme des flux en direct provenant de deux caméras et microphones. Chaque personne peut voir et entendre ce que l'autre partage en temps réel, comme lors d'un appel vidéo en direct.

7. Processus de signalisation
Le processus de signalisation implique l'échange d'offres, de réponses et de candidats ICE via le serveur. Cela garantit que les deux clients disposent des informations nécessaires pour établir une PeerConnection directe.

Analogie : Le processus de signalisation est comme un système postal délivrant des messages entre deux personnes souhaitant se connecter. Le facteur (serveur) s'assure que les lettres (offres, réponses) parviennent au bon destinataire pour que la conversation puisse commencer.

Le défi du double rôle

Pour comprendre la conception, il est important de d’abord saisir un défi clé.

Dans un appel téléphonique traditionnel, le processus de connexion implique qu'une personne agisse en tant qu'appelant et l'autre en tant que destinataire. Cependant, dans une application de chat comme celle-ci, la situation est différente. Ici, chaque utilisateur établit une connexion et attend que quelqu'un d'autre l'accepte. Cela signifie que chacun doit fonctionner à la fois comme appelant et comme destinataire simultanément, créant ainsi un système où les deux rôles fusionnent pour faciliter la fluidité.

C'est pourquoi j'ai utilisé deux connexions peer, peer1 et peer2.

Quelques fonctions importantes :

OnIceCandidateFunc
Gère l’échange de candidats ICE pour établir une connexion peer-to-peer. Il envoie les candidats ICE au serveur lorsque les candidats Ice sont reçus du serveur STUN.

OnTrackFunc
Gère les pistes multimédias (audio/vidéo) reçues du homologue. Activé lorsqu'un homologue transmet des pistes. Affiche les médias sur l'interface du récepteur.

handle_ice
Gère les candidats sur glace reçus d'un autre client. Il ajoute les candidats glace reçus et les ajoute à la connexion homologue.

ObtenirRandomUser
Cette fonction sélectionne un utilisateur aléatoire dans une liste d'utilisateurs en ligne, à l'exclusion de l'utilisateur actuel. Si la liste est vide, une erreur est générée. Cela garantit un appariement aléatoire équitable pour le chat.

Envoyermatch
Cette fonction envoie une demande de connexion au serveur pour un utilisateur aléatoire sélectionné. Il construit un message WebSocket, informant le serveur de l'intention de se connecter.

Checkmatch
Cette fonction vérifie si la réponse du serveur confirme une correspondance réussie. Il vérifie que quelqu'un d'autre a sélectionné cet utilisateur. Il vérifie si cet utilisateur a sélectionné les autres utilisateurs. Il vérifie si l'indicateur call_clicked est vrai (il est important que l'autre utilisateur ait également cliqué sur appeler).

Si toutes les conditions sont remplies, cela renvoie vrai ; sinon, il renvoie false. Cette étape garantit que la connexion est correctement validée avant de continuer.

Exemple pour comprendre le processus de mise en correspondance

Les deux côtés enverront et recevront, le côté qui reçoit en premier est pris

Processus de connexion Webrtc

Pair 1 et Pair 2
Pour établir une connexion, deux pairs, Peer 1 et Peer 2, jouent des rôles distincts :

Peer 1 : Responsable de la création d'une offre et de la réception d'une réponse.
Peer 2 : gère l'offre, génère une réponse et la renvoie.
Processus de connexion
Voici comment se déroule le processus de connexion une fois la correspondance établie :

1 Initialisation du pair 1 :
Le homologue 1 est créé sur les deux clients (par exemple, Client 1 et Client 2).
Deux événements clés sont rattachés au Peer 1 :
OnTrackFunc : gère les flux audio/vidéo entrants de l'autre homologue.
OnIceCandidateFunc : envoie des candidats ICE au serveur chaque fois que de nouveaux candidats sont reçus du serveur STUN.

2 Création et envoi de l'offre :
Le homologue 1 génère une offre, qui est définie comme sa description locale.
Cette offre est envoyée à l'utilisateur correspondant (via le serveur de signalisation) par les deux clients.
3 Gérer l'offre avec le pair 2 :

Dès réception de l'offre, Peer 2 est créé des deux côtés.
Semblable à Peer 1, Peer 2 est initialisé avec les événements OnTrackFunc et OnIceCandidateFunc.
L’offre reçue est définie comme télécommandeDescription du Peer 2.

4 Générer et envoyer la réponse :
Le pair 2 génère une réponse, qui est définie comme sa description locale.
Cette réponse est renvoyée à l'autre client (via le serveur) des deux côtés.

5 Terminer la connexion :
Une fois la réponse reçue, elle est définie comme télécommandeDescription du homologue 1.
Les deux clients disposent désormais des informations requises pour établir une connexion directe.

Les deux parties enverront et recevront

6 Gestion des candidats ICE :
Au fur et à mesure que les candidats ICE sont échangés, OnIceCandidateFunc est déclenché.
Les candidats ICE reçus sont traités à l'aide de la fonction handle_ice, qui les ajoute au pair approprié (Peer 1 ou Peer 2) en fonction de la configuration de la connexion.

7 Configuration des flux multimédias :
L'événement OnTrackFunc est déclenché lors de la réception de pistes multimédias (audio/vidéo).
Cela garantit que les flux vidéo et audio distants sont affichés sur les deux clients.

Les deux parties enverront et recevront

Le processus de connexion ne se produit pas simultanément des deux côtés en raison du caractère aléatoire de la sélection des utilisateurs et des délais de traitement. Le client qui termine la configuration en premier devient « l’appelant », tandis que l’autre agit en tant que « récepteur ».

Une fois la connexion WebRTC établie avec succès, les deux utilisateurs peuvent profiter d'une expérience de chat vidéo fluide.

Mettre fin à l'appel

Terminer correctement un appel WebRTC est essentiel pour éviter des problèmes lors de connexions futures, tels que des fuites de ressources ou des erreurs lors de la reconnexion. Voici un guide détaillé pour gérer correctement la terminaison d’appel :

1 Supprimer les candidats ICE :
Les candidats ICE sont utilisés pour établir une connexion entre pairs.
Avant de mettre fin à l'appel, effacez tous les candidats ICE stockés pour vous assurer qu'ils n'interfèrent pas avec les connexions futures.

2 Avertir l'autre client :
Informez l'autre client que l'appel est terminé.
Cela peut être fait via le serveur de signalisation pour mettre fin gracieusement à la connexion des deux côtés.

3 Supprimer les pistes de la connexion homologue :
Supprimez toutes les pistes multimédias (audio/vidéo) associées à la connexion homologue pour libérer des ressources.
Cela empêche la poursuite des flux multimédias après la fin de l'appel.

4 Réinitialiser l'état de l'appel :
Définissez la variable call_clicked sur null (ou son équivalent dans votre application).
Cela garantit que l'application sait qu'aucun appel actif n'est en cours.
Réinitialisez Peer 1 et Peer 2 à null.
Cela libère la mémoire allouée aux connexions homologues et évite la réutilisation accidentelle d'anciens objets.
Définissez RemoteStream sur null.
Cela garantit que le flux audio/vidéo distant est effacé de l'interface de l'application.

un seul côté, car un seul des clients initie la fin

Conclusion

Créer une application de chat vidéo aléatoire est aussi excitant que d'en utiliser une ! Le processus comporte son lot de défis et d'opportunités d'apprentissage, mais la satisfaction de voir votre création prendre vie est vraiment gratifiante.

Étudiant en 3ème année d'informatique, j'ai mis ma passion et ma curiosité dans ce projet. Même si j’ai fait de mon mieux pour que tout fonctionne correctement, il y a toujours place à l’amélioration. Si vous remarquez des défauts ou avez des suggestions pour améliorer ce projet, n'hésitez pas à me contacter — j'aimerais apprendre de vos idées !

Alors, prenez votre clavier, plongez dans le code et qui sait, vous pourriez bien créer la prochaine grande nouveauté en matière de communication en ligne.

Bon codage ! ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!