Webrtc、Websocket、Django を使用してランダム ビデオ チャット Web アプリを構築する方法。

大学 2 年生のとき、私と友人は Omegle で何時間も過ごし、世界中から集まったランダムな人々とチャットしていました。それはいつも楽しみと驚きの組み合わせでした。次に誰に会えるかわかりませんでした。 Omegle がシャットダウンすると、空白が残りました。私たちはそれらのランダムなつながりの興奮を懐かしく思い、そのとき「自分のバージョンを構築してみたらどうだろう?」と思いました

このブログでは、WebRTC と WebSocket を使用してそのようなプラットフォームを設計および構築するプロセスを詳しく説明し、私が直面した課題とそれをどのように克服したかを強調します。このブログを読み終えるまでに、その仕組みを理解できるだけでなく、独自のリアルタイム コミュニケーション アプリケーションの構築を開始するための強固な基盤も得られるでしょう

私は現在、Noto Chats というプロジェクトに取り組んでいます。これには、このランダムなビデオチャット機能と他のいくつかのエキサイティングな機能が含まれています。システムは徹底的にテストされており、シームレスに動作します。

ramdomvideo チャット アプリのコード リンクは次のとおりです https://github.com/Arsh910/RandomVideo-Chat-app

技術スタック

フロントエンド: インタラクティブなユーザー インターフェイスを構築するための ReactJS。
バックエンド: WebSocket 接続を処理するための Django チャネル。
シグナリング プロトコル: WebRTC 接続を確立するための WebSocket。
メディア ストリーミング: ピアツーピアのビデオおよび音声通信用の WebRTC。

デザイン

両側のピアは接続を試み、最初に接続した方が続行します

設計のコンポーネント:

WebRTC の仕組みに詳しくない場合は、私が学んだこのビデオをご覧ください。コンポーネントの概要を以下に示します

1.クライアント 1 とクライアント 2
これらは、接続しようとしている 2 人のユーザーを表します。各クライアントは、オファーを作成し、サーバーに送信し、受信したオファーに応答する責任があります。

例え: クライアント 1 とクライアント 2 を、会話をしたい 2 人として考えてみましょう。彼らはまだお互いのことを知りませんが、話したいと思っています。それぞれが率先して連絡を取り、相手の応答を待ちます。

2.サーバー
サーバーは仲人として機能します。実際の会話は処理しませんが、クライアント間でオファーと回答を渡し、接続詳細の交換を支援することで導入を促進します。

例え: 共通の友人がパーティーで 2 人を紹介すると想像してください。友人は会話に参加しませんが、会話を始めるためにお互いの名前と電話番号を知っていることを確認します。

3. PeerConnection
PeerConnection は、2 つのクライアント間に直接リンクを確立するメカニズムです。メディア (オーディオ/ビデオ) の交換を管理し、一度セットアップされた接続が安定した状態を維持できるようにします。上の図のピア 1 とピア 2 のように。

例え: PeerConnection は、2 つの家の間にある安全なプライベート トンネルのようなものです。トンネルが建設されると、中の人は誰にも見られずにメモを渡したり、話したり、荷物を送ることさえできるようになります。

4. ICE 候補者
ICE (対話型接続確立) の候補は、直接接続の構成要素です。これらは、PeerConnection が最適な接続を確立するために使用しようとするルートとネットワーク パスです。

例え: ICE 候補は、2 つの家を結ぶ複数の道路を示す地図のようなものです。接続は最適な道路 (最短、スムーズ) を見つけ、それを使用して迅速かつ信頼性の高いルートを確保します。

5.提案と回答
接続プロセスは、1 つのクライアント (発信者) がオファーを作成し、それをサーバー経由で他のクライアントに送信することから始まります。 2 番目のクライアント (受信者) は応答を作成し、それを送り返します。この交換により接続が確立されます。

例え: ある人が「友達になろう!」という手紙を送っていると想像してください。相手は「もちろん、私もそれが欲しいです！」と答えます。彼らが同意すると、友情が始まります。

6.トラック (オーディオ/ビデオ ストリーム)
トラックとは、接続が確立されるとクライアント間で共有されるメディア ストリーム (オーディオとビデオ) を指します。

例え: トラックは 2 台のカメラとマイクからのライブ フィードのようなものです。各人は、ライブビデオ通話のように、相手が共有しているものをリアルタイムで見たり聞いたりすることができます。

7.シグナル伝達プロセス
シグナリング プロセスには、サーバーを介したオファー、回答、ICE 候補の交換が含まれます。これにより、両方のクライアントが直接 PeerConnection を確立するために必要な情報を確実に持つことができます。

例え: シグナリングプロセスは、つながりを求める 2 人の間にメッセージを届ける郵便システムに似ています。郵便配達員 (サーバー) は、手紙 (オファー、回答) が適切な受信者に確実に届くようにし、会話を開始できるようにします。

二重の役割への挑戦

デザインを理解するには、まず主要な課題を把握することが重要です。

従来の電話通話では、接続プロセスには、1 人が発信者となり、もう 1 人が受信者として機能します。ただし、このようなチャットアプリでは状況が異なります。ここでは、すべてのユーザーが接続を開始し、他のユーザーが接続を受け入れるのを待っています。これは、誰もが発信者と受信者の両方として同時に機能する必要があり、両方の役割が融合してシームレスを促進するシステムを作成する必要があることを意味します。

そのため、ピア 1 とピア 2 の 2 つのピア接続を使用しました。

いくつかの重要な機能:

OnIceCandidateFunc
ピアツーピア接続を確立するための ICE 候補交換を処理します。 STUNサーバーからIce候補を受信すると、ICE候補をサーバーに送信します。

OnTrackFunc
ピアから受信したメディア トラック (オーディオ/ビデオ) を処理します。ピアがトラックを送信するとアクティブになります。受信機のインターフェースにメディアを表示します。

ハンドルアイス
他のクライアントから受け取った氷候補を処理します。受信したアイス候補を追加し、ピア接続に追加します。

GetRandomUser
この関数は、オンライン ユーザーのリストから現在のユーザーを除くランダムなユーザーを選択します。リストが空の場合は、エラーがスローされます。これにより、チャットの公平なランダム ペアリングが保証されます。

マッチを送信
この関数は、選択されたランダムなユーザーのサーバーに接続リクエストを送信します。 WebSocket メッセージを構築し、サーバーに接続の意図を通知します。

チェックマッチ
この関数は、サーバーの応答で一致が成功したことを確認するかどうかを検証します。他の誰かがこのユーザーを選択したかどうかを確認します。このユーザーが他のユーザーを選択したかどうかを確認します。 call_clicked フラグが true かどうかを確認します (他のユーザーも通話をクリックしたことが重要です)。

すべての条件が満たされる場合は true を返します。それ以外の場合は false を返します。この手順により、続行する前に接続が適切に検証されていることを確認できます。

マッチングプロセスを理解するための例

双方が送信と受信を行い、最初に受信した側が取られます

Webrtc接続プロセス

ピア 1 およびピア 2
接続を確立するには、2 つのピア (ピア 1 とピア 2) が異なる役割を果たします。

ピア 1: オファーの作成と回答の受信を担当します。
ピア 2: オファーを処理し、回答を生成し、返信します。
接続プロセス
マッチング後の接続プロセスは次のとおりです:

1 ピア 1 を初期化しています:
ピア 1 は両方のクライアント (例: クライアント 1 とクライアント 2) で作成されます。
2 つの主要なイベントがピア 1 に関連付けられています:
OnTrackFunc: 他のピアから受信するオーディオ/ビデオ ストリームを管理します。
OnIceCandidateFunc: STUN サーバーから新しい候補を受信するたびに、ICE 候補をサーバーに送信します。

2 オファーの作成と送信:
ピア 1 は、localDescription として設定されるオファーを生成します。
このオファーは、両方のクライアントによって (シグナリング サーバー経由で) 一致したユーザーに送信されます。
3 ピア 2 によるオファーの処理:

オファーを受信すると、両側でピア 2 が作成されます。
ピア 1 と同様に、ピア 2 は OnTrackFunc イベントと OnIceCandidateFunc イベントで初期化されます。
受信したオファーはピア 2 の RemoteDescription として設定されます。

4 回答の生成と送信:
ピア 2 は、localDescription として設定される回答を生成します。
この回答は、両側から (サーバー経由で) 他のクライアントに返送されます。

5 接続の完了:
応答を受信すると、ピア 1 の RemoteDescription として設定されます。
これで、両方のクライアントが直接接続を確立するために必要な情報を取得しました。

双方が送受信します

6 ICE 候補の処理:
ICE 候補が交換されると、OnIceCandidateFunc がトリガーされます。
受信した ICE 候補は handle_ice 関数を使用して処理され、接続設定に基づいて適切なピア (ピア 1 またはピア 2) に追加されます。

7 メディア ストリームの設定:
OnTrackFunc イベントは、メディア トラック (オーディオ/ビデオ) が受信されるとトリガーされます。
これにより、リモートのビデオとオーディオのストリームが両方のクライアントに表示されるようになります。

双方が送受信します

ユーザー選択のランダム性と処理の遅延のため、接続プロセスは両側で同時に行われません。最初にセットアップを完了したクライアントが「呼び出し元」となり、もう一方のクライアントが「受信者」として機能します。

WebRTC 接続が正常に確立されると、両方のユーザーがシームレスなビデオ チャット エクスペリエンスを楽しむことができます。

通話を終了する

WebRTC 呼び出しを適切に終了することは、再接続時のリソース リークやエラーなど、今後の接続中に発生する問題を回避するために不可欠です。通話終了を適切に処理するための詳細なガイドは次のとおりです:

1 ICE 候補を削除します:
ICE 候補は、ピア間の接続を確立するために使用されます。
通話を終了する前に、保存されている ICE 候補をクリアして、今後の接続に干渉しないようにしてください。

2 他のクライアントに通知します:
通話が終了することを他のクライアントに通知します。
これはシグナリング サーバーを介して実行され、両側の接続を正常に終了できます。

3 ピア接続からトラックを削除します:
ピア接続に関連付けられているメディア トラック (オーディオ/ビデオ) を削除して、リソースを解放します。
これにより、通話終了後のメディア ストリームの継続が妨げられます。

4 通話状態のリセット:
変数 call_clicked を null (またはアプリケーション内の同等のもの) に設定します。
これにより、アプリケーションはアクティブな通話が進行中でないことを確実に認識します。
ピア 1 とピア 2 を null にリセットします。
これにより、ピア接続に割り当てられたメモリが解放され、古いオブジェクトの誤った再利用が回避されます。
RemoteStream を null に設定します。
これにより、リモートのオーディオ/ビデオ ストリームがアプリケーション インターフェイスから確実にクリアされます。

一方のみ、クライアントの 1 つだけが終了を開始するため

まとめ

ランダムビデオチャットアプリを構築するのは、アプリを使用するのと同じくらい楽しいです!このプロセスには、相応の課題や学習の機会が伴いますが、自分の作品が現実になるのを見る満足感は、本当にやりがいのあるものです。

コンピューター サイエンスの 3 年生として、私はこのプロジェクトに情熱と好奇心を注ぎ込んできました。すべてがシームレスに機能するよう最善を尽くしてきましたが、改善の余地は常にあります。何か欠陥に気づいた場合、またはこのプロジェクトをより良くするための提案がある場合は、遠慮なく私に連絡してください。私はあなたの洞察から学びたいと思っています!

それでは、キーボードを手に取り、コードに飛び込んでみましょう。そうすれば、オンライン コミュニケーションで次の大きなものを生み出すことができるかもしれません。

コーディングを楽しんでください! ?

以上がWebrtc、Websocket、Django を使用してランダム ビデオ チャット Web アプリを構築する方法。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。