So erstellen Sie eine Web-App für zufällige Video-Chats mit Webrtc, Websocket und Django.

In meinem zweiten Studienjahr verbrachten ich und mein Freund stundenlang auf Omegle und unterhielten uns mit zufälligen Leuten aus der ganzen Welt. Es war immer eine Mischung aus Spaß und Überraschung – man wusste nie, wen man als nächstes treffen würde. Als Omegle geschlossen wurde, hinterließ es eine Lücke. Wir haben die Aufregung dieser zufälligen Verbindungen vermisst, und da dachte ich: „Warum nicht meine eigene Version davon erstellen?“

In diesem Blog werde ich den Prozess des Entwerfens und Aufbaus einer solchen Plattform mithilfe von WebRTC und WebSockets aufschlüsseln und die Herausforderungen hervorheben, mit denen ich konfrontiert war, und wie ich sie gemeistert habe. Am Ende dieses Blogs werden Sie nicht nur verstehen, wie es funktioniert, sondern auch über eine solide Grundlage verfügen, um mit der Entwicklung Ihrer eigenen Echtzeit-Kommunikationsanwendung zu beginnen

Ich arbeite derzeit an einem Projekt namens Noto Chats, das diese zufällige Video-Chat-Funktion zusammen mit mehreren anderen aufregenden Funktionen umfasst. Das System wurde gründlich getestet und funktioniert einwandfrei.

Hier ist der Code-Link für die Ramdomvideo-Chat-App https://github.com/Arsh910/RandomVideo-Chat-app

Der Tech-Stack

Frontend: ReactJS zum Aufbau einer interaktiven Benutzeroberfläche.
Backend: Django-Kanäle für die Handhabung von WebSocket-Verbindungen.
Signalisierungsprotokoll: WebSockets zum Herstellen von WebRTC-Verbindungen.
Medien-Streaming: WebRTC für Peer-to-Peer-Video- und Audiokommunikation.

Design

Die Gleichaltrigen auf beiden Seiten werden versuchen, eine Verbindung herzustellen, derjenige, der es zuerst herstellt, wird fortfahren

Bestandteile des Designs:

Wenn Sie nicht mit der Funktionsweise von WebRTC vertraut sind, schauen Sie sich dieses Video an, aus dem ich gelernt habe. Hier ein kurzer Überblick über die Komponenten

1. Kunde 1 und Kunde 2
Diese stellen die beiden Benutzer dar, die versuchen, eine Verbindung herzustellen. Jeder Kunde ist dafür verantwortlich, Angebote zu erstellen, sie an den Server zu senden und auf erhaltene Angebote zu reagieren.

Analogie: Stellen Sie sich Kunde 1 und Kunde 2 als zwei Personen vor, die ein Gespräch führen möchten. Sie kennen sich noch nicht, sind aber gespannt auf ein Gespräch. Jeder ergreift die Initiative, greift auf den anderen zu und wartet darauf, dass er antwortet.

2. Server
Der Server fungiert als Matchmaker. Es kümmert sich nicht um das eigentliche Gespräch, sondern erleichtert die Einführung, indem es Angebote und Antworten zwischen Kunden weiterleitet und dabei hilft, Verbindungsdetails auszutauschen.

Analogie: Stellen Sie sich vor, ein gemeinsamer Freund stellt zwei Personen auf einer Party vor. Der Freund beteiligt sich nicht an der Unterhaltung, stellt aber sicher, dass er die Namen und Nummern des anderen kennt, um mit dem Gespräch zu beginnen.

3. PeerConnection
Die PeerConnection ist der Mechanismus, der die direkte Verbindung zwischen den beiden Clients herstellt. Es verwaltet den Medienaustausch (Audio/Video) und stellt sicher, dass die Verbindung nach dem Aufbau stabil bleibt. Wie Peer1 und Peer 2 im Bild oben.

Analogie: PeerConnection ist wie ein sicherer, privater Tunnel zwischen zwei Häusern. Sobald der Tunnel gebaut ist, können die Menschen darin Notizen weitergeben, reden oder sogar Pakete verschicken, ohne dass es jemand anderes sieht.

4. ICE-Kandidaten
ICE-Kandidaten (Interactive Connectivity Establishment) sind die Bausteine ​​für die direkte Verbindung. Dies sind die Routen und Netzwerkpfade, die PeerConnection zu verwenden versucht, um die beste Verbindung herzustellen.

Analogie: ICE-Kandidaten sind wie Karten, die mehrere Straßen zeigen, um zwei Häuser zu verbinden. Die Verbindung findet die beste Straße (kürzeste, glatteste) und nutzt sie, um eine schnelle und zuverlässige Route zu gewährleisten.

5. Angebot und Antwort
Der Verbindungsprozess beginnt damit, dass ein Client (Anrufer) ein Angebot erstellt und es über den Server an den anderen Client sendet. Der zweite Client (Receiver) erstellt eine Antwort und sendet sie zurück. Dieser Austausch stellt die Verbindung her.

Analogie: Stellen Sie sich vor, eine Person schickt einen Brief mit den Worten: „Lass uns Freunde sein!“ Die andere Person antwortet: „Klar, das hätte ich auch gerne!“ Sobald sie einverstanden sind, beginnt die Freundschaft.

6. Tracks (Audio-/Video-Streams)
Tracks beziehen sich auf die Medienströme (Audio und Video), die zwischen den Clients geteilt werden, sobald die Verbindung hergestellt ist.

Analogie: Tracks sind wie Live-Feeds von zwei Kameras und Mikrofonen. Jede Person kann in Echtzeit sehen und hören, was die andere teilt, wie bei einem Live-Videoanruf.

7. Signalisierungsprozess
Der Signalisierungsprozess umfasst den Austausch von Angeboten, Antworten und ICE-Kandidaten über den Server. Dadurch wird sichergestellt, dass beide Clients über die notwendigen Informationen verfügen, um eine direkte PeerConnection aufzubauen.

Analogie: Der Signalisierungsprozess ist wie ein Postsystem, das Nachrichten zwischen zwei Personen übermittelt, die eine Verbindung herstellen möchten. Der Postbote (Server) sorgt dafür, dass die Briefe (Angebote, Antworten) den richtigen Empfänger erreichen, damit das Gespräch beginnen kann.

Die Doppelrollen-Herausforderung

Um das Design zu verstehen, ist es wichtig, zunächst eine zentrale Herausforderung zu begreifen.

Bei einem herkömmlichen Telefonanruf fungiert beim Verbindungsaufbau eine Person als Anrufer und die andere als Empfänger. Bei einer Chat-App wie dieser ist die Situation jedoch anders. Hier initiiert jeder Benutzer sowohl eine Verbindung als auch wartet darauf, dass jemand anderes sie akzeptiert. Das bedeutet, dass jeder gleichzeitig als Anrufer und Empfänger fungieren muss, um ein System zu schaffen, in dem beide Rollen nahtlos verschmelzen.

Deshalb habe ich zwei Peer-Verbindungen verwendet, Peer1 und Peer2.

Einige wichtige Funktionen:

OnIceCandidateFunc
Verwaltet den ICE-Kandidatenaustausch zum Aufbau einer Peer-to-Peer-Verbindung. Es sendet ICE-Kandidaten an den Server, wenn Ice-Kandidaten vom STUN-Server empfangen werden.

OnTrackFunc
Verarbeitet vom Peer empfangene Medienspuren (Audio/Video). Wird aktiviert, wenn ein Peer Tracks überträgt. Zeigt Medien auf der Schnittstelle des Empfängers an.

handle_ice
Verarbeitet die von anderen Kunden erhaltenen Ice-Kandidaten. Es fügt die empfangenen Ice-Kandidaten hinzu und fügt sie der Peer-Verbindung hinzu.

GetRandomUser
Diese Funktion wählt einen zufälligen Benutzer aus einer Liste von Online-Benutzern aus, wobei der aktuelle Benutzer ausgeschlossen ist. Wenn die Liste leer ist, wird ein Fehler ausgegeben. Dies gewährleistet eine faire Zufallspaarung für den Chat.

Sendmatch
Diese Funktion sendet für einen ausgewählten zufälligen Benutzer eine Verbindungsanfrage an den Server. Es erstellt eine WebSocket-Nachricht und informiert den Server über die Absicht, eine Verbindung herzustellen.

Checkmatch
Diese Funktion überprüft, ob die Antwort des Servers eine erfolgreiche Übereinstimmung bestätigt. Es wird überprüft, ob jemand anderes diesen Benutzer ausgewählt hat. Es wird geprüft, ob dieser Benutzer die anderen Benutzer ausgewählt hat. Es prüft, ob das Flag „calling_clicked“ wahr ist (es ist wichtig, dass auch ein anderer Benutzer auf „Anrufen“ geklickt hat).

Wenn alle Bedingungen erfüllt sind, wird „true“ zurückgegeben. andernfalls wird false zurückgegeben. Dieser Schritt stellt sicher, dass die Verbindung ordnungsgemäß validiert wird, bevor Sie fortfahren.

Beispiel zum Verständnis des Matching-Prozesses

Beide Seiten werden senden und empfangen, die Seite, die zuerst empfängt, wird genommen

Webrtc-Verbindungsprozess

Peer 1 und Peer 2
Um eine Verbindung herzustellen, spielen zwei Peers, Peer 1 und Peer 2, unterschiedliche Rollen:

Peer 1: Verantwortlich für die Erstellung eines Angebots und den Erhalt einer Antwort.
Peer 2: Bearbeitet das Angebot, generiert eine Antwort und sendet sie zurück.
Verbindungsprozess
So läuft der Verbindungsprozess ab, nachdem eine Übereinstimmung hergestellt wurde:

1 Peer 1 wird initialisiert:
Peer 1 wird auf beiden Clients erstellt (z. B. Client 1 und Client 2).
Zwei Schlüsselereignisse sind mit Peer 1 verbunden:
OnTrackFunc: Verwaltet eingehende Audio-/Videostreams vom anderen Peer.
OnIceCandidateFunc: Sendet ICE-Kandidaten an den Server, wenn neue Kandidaten vom STUN-Server empfangen werden.

2 Angebot erstellen und versenden:
Peer 1 generiert ein Angebot, das als seine localDescription festgelegt wird.
Dieses Angebot wird von beiden Clients an den passenden Benutzer gesendet (über den Signalisierungsserver).
3 Bearbeitung des Angebots mit Peer 2:

Nach Erhalt des Angebots wird auf beiden Seiten Peer 2 erstellt.
Ähnlich wie Peer 1 wird Peer 2 mit den Ereignissen OnTrackFunc und OnIceCandidateFunc initialisiert.
Das empfangene Angebot wird als RemoteDescription von Peer 2 festgelegt.

4 Generieren und Senden der Antwort:
Peer 2 generiert eine Antwort, die als seine localDescription festgelegt wird.
Diese Antwort wird von beiden Seiten an den anderen Client (über den Server) zurückgesendet.

5 Herstellen der Verbindung:
Sobald die Antwort empfangen wurde, wird sie als RemoteDescription von Peer 1 festgelegt.
Beide Clients verfügen nun über die erforderlichen Informationen, um eine direkte Verbindung herzustellen.

Beide Seiten senden und empfangen

6 Umgang mit ICE-Kandidaten:
Wenn die ICE-Kandidaten ausgetauscht werden, wird die OnIceCandidateFunc ausgelöst.
Empfangene ICE-Kandidaten werden mit der Funktion handle_ice verarbeitet, die sie basierend auf dem Verbindungsaufbau dem entsprechenden Peer (Peer 1 oder Peer 2) hinzufügt.

7 Einrichten von Medienstreams:
Das OnTrackFunc-Ereignis wird ausgelöst, wenn Medientitel (Audio/Video) empfangen werden.
Dadurch wird sichergestellt, dass die Remote-Video- und Audiostreams auf beiden Clients angezeigt werden.

Beide Seiten senden und empfangen

Aufgrund der Zufälligkeit der Benutzerauswahl und der Verarbeitungsverzögerungen findet der Verbindungsvorgang nicht auf beiden Seiten gleichzeitig statt. Der Client, der die Einrichtung zuerst abschließt, wird zum „Anrufer“, während der andere als „Empfänger“ fungiert.

Sobald die WebRTC-Verbindung erfolgreich hergestellt wurde, können beide Benutzer ein nahtloses Video-Chat-Erlebnis genießen.

Beenden des Anrufs

Das ordnungsgemäße Beenden eines WebRTC-Aufrufs ist wichtig, um Probleme bei zukünftigen Verbindungen zu vermeiden, wie z. B. Ressourcenlecks oder Fehler beim erneuten Verbinden. Hier ist eine detaillierte Anleitung zum ordnungsgemäßen Umgang mit der Anrufbeendigung:

1 ICE-Kandidaten entfernen:
ICE-Kandidaten werden verwendet, um eine Verbindung zwischen Gleichgesinnten herzustellen.
Bevor Sie den Anruf beenden, löschen Sie alle gespeicherten ICE-Kandidaten, um sicherzustellen, dass sie zukünftige Verbindungen nicht beeinträchtigen.

2 Benachrichtigen Sie den anderen Kunden:
Informieren Sie den anderen Kunden darüber, dass der Anruf beendet wird.
Dies kann über den Signalisierungsserver erfolgen, um die Verbindung auf beiden Seiten ordnungsgemäß zu beenden.

3 Spuren aus der Peer-Verbindung entfernen:
Entfernen Sie alle mit der Peer-Verbindung verbundenen Medienspuren (Audio/Video), um Ressourcen freizugeben.
Dies verhindert die Fortsetzung von Medienströmen nach Beendigung des Anrufs.

4 Anrufstatus zurücksetzen:
Setzen Sie die Variable „calling_clicked“ auf null (oder das Äquivalent in Ihrer Anwendung).
Dadurch wird sichergestellt, dass die Anwendung weiß, dass kein aktiver Anruf stattfindet.
Setzen Sie Peer 1 und Peer 2 auf Null zurück.
Dadurch wird der für Peer-Verbindungen zugewiesene Speicher freigegeben und eine versehentliche Wiederverwendung alter Objekte vermieden.
Setzen Sie remoteStream auf null.
Dadurch wird sichergestellt, dass der Remote-Audio-/Videostream von der Anwendungsschnittstelle gelöscht wird.

nur eine Seite, da nur einer der Kunden das Ende initiiert

Zusammenfassung

Das Erstellen einer zufälligen Video-Chat-App ist genauso aufregend wie die Verwendung einer solchen! Der Prozess bringt eine Menge Herausforderungen und Lernmöglichkeiten mit sich, aber die Befriedigung, zu sehen, wie Ihre Kreation zum Leben erweckt wird, ist wirklich lohnend.

Als Informatikstudent im dritten Jahr habe ich meine Leidenschaft und Neugier in dieses Projekt gesteckt. Obwohl ich mein Bestes getan habe, um sicherzustellen, dass alles reibungslos funktioniert, gibt es immer Raum für Verbesserungen. Wenn Sie Mängel bemerken oder Vorschläge zur Verbesserung dieses Projekts haben, zögern Sie bitte nicht, mich zu kontaktieren – ich würde gerne aus Ihren Erkenntnissen lernen!

Also, schnappen Sie sich Ihre Tastatur, tauchen Sie in den Code ein und wer weiß – vielleicht erschaffen Sie das nächste große Ding in der Online-Kommunikation.

Viel Spaß beim Codieren! ?

Das obige ist der detaillierte Inhalt vonSo erstellen Sie eine Web-App für zufällige Video-Chats mit Webrtc, Websocket und Django.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!