Google jest zaangażowana w pogłębianie równości rasowej dla czarnych społecznościach. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Rozpoczęcie korzystania z połączeń równorzędnych

peer jest częścią specyfikacji WebRTC że dotyczy połączenia dwóch aplikacji na różnych komputerach do komunikacji z wykorzystaniem protokołu peer-to-peer. Komunikacja między rówieśnikami może być wideo, dane audio lub arbitralne binarny (dla klientów wspierających RTCDataChannel API). Aby dowiedzieć się, jak połączyć dwa rówieśnicy mogą oba klienci muszą zapewnić ICE konfigurację serwera. Jest to albo STUN lub TURN-serwer, a ich zadaniem jest zapewnienie ICE kandydatów do każdego klienta, który jest następnie przenoszony do zdalnego każdym. To przeniesienie lodu kandydatów jest powszechnie nazywany sygnalizacji.

Sygnalizacja

Specyfikacja obejmuje WebRTC API do komunikacji z serwerem ICE (Internet Connectivity Establishment), ale składnik sygnalizacja nie jest jego częścią. Sygnalizacja jest niezbędna dla dwóch rówieśników do udziału, jak powinny się połączyć. Zwykle jest to rozwiązane poprzez regularny opartego na protokole HTTP Web API (czyli usługa REST lub inny mechanizm RPC), gdzie aplikacje internetowe mogą przekazywać niezbędne informacje przed peer jest inicjowany.

Kod obserwacji fragment kodu pokazuje, jak to fikcyjne usługi sygnalizacja może być używane do wysyłania i odbierania wiadomości asynchronicznie. W ten sposób można stosować w przypadkach pozostałych przykładach tej prowadnicy jest to konieczne.

 // Set up an asynchronous communication channel that will be
// used during the peer connection setup
const signalingChannel = new SignalingChannel(remoteClientId);
signalingChannel.addEventListener('message', message => {
    // New message from remote client received
});

// Send an asynchronous message to the remote client
signalingChannel.send('Hello!');
 

Sygnalizacji mogą być realizowane na wiele różnych sposobów, a specyfikacja WebRTC nie preferuje żadnego konkretnego rozwiązania.

Inicjowanie połączeń peer

Każdy peer jest obsługiwane przez RTCPeerConnection obiektu. Konstruktor tej klasy pobiera pojedynczy RTCConfiguration obiekt jako jego parametr. Obiekt ten określa sposób peer jest ustawione i powinno zawierać informacje o serwerach lodowej do użytku.

Po RTCPeerConnection jest tworzony musimy stworzyć ofertę SDP lub odpowiedzi, w zależności czy jesteśmy nazywając Peer lub odbierającego. Po utworzeniu oferta SDP lub odpowiedź należy przesłać do zdalnego każdym innym kanałem. Przechodząc do odległych obiektów SDP rówieśników nazywa sygnalizacji i nie jest objęte specyfikacją WebRTC.

Aby zainicjować instalację peer od wywołującego strony, tworzymy RTCPeerConnection obiekt, a następnie zadzwonić createOffer() , aby utworzyć RTCSessionDescription obiekt. Ten opis sesja jest ustawiona jako lokalnego opisem użyciu setLocalDescription() , a następnie przesyłane do naszego kanału sygnalizacyjnego po stronie odbiorczej. Mamy również skonfigurować słuchacza do naszego kanału sygnalizacyjnego, gdy odpowiedź na oferowanymi opisem sesji jest odbierany od strony odbiorczej.

 async function makeCall() {
    const configuration = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]}
    const peerConnection = new RTCPeerConnection(configuration);
    signalingChannel.addEventListener('message', async message => {
        if (message.answer) {
            const remoteDesc = new RTCSessionDescription(message.answer);
            await peerConnection.setRemoteDescription(remoteDesc);
        }
    });
    const offer = await peerConnection.createOffer();
    await peerConnection.setLocalDescription(offer);
    signalingChannel.send({'offer': offer});
}
 

Na stronie otrzymującego, czekamy na oferty przychodzącej przed tworzymy naszą RTCPeerConnection instancji. Gdy to zrobisz możemy ustawić odebrany ofertę używając setRemoteDescription() . Następnie nazywamy createAnswer() , aby utworzyć odpowiedź na otrzymane oferty. Ta odpowiedź jest ustawiony jako lokalny opisem użyciu setLocalDescription() a następnie wysłany do wywołującego siebie na naszym serwerze sygnalizacji.

 const peerConnection = new RTCPeerConnection(configuration);
signalingChannel.addEventListener('message', async message => {
    if (message.offer) {
        peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer));
        const answer = await peerConnection.createAnswer();
        await peerConnection.setLocalDescription(answer);
        signalingChannel.send({'answer': answer});
    }
});
 

Po dwóch rówieśników ustawiono zarówno lokalnych i zdalnych opisów sesji znają możliwości zdalnego każdym. To nie znaczy, że połączenie między rówieśnikami jest gotowy. Aby to zadziałało musimy zbierać lodzie kandydatów na każdym z każdym i transferu (w kanale sygnalizacyjnym) do innego równorzędnego.

ICE kandydatów

Przed dwa rówieśnicy mogą communitcate użyciu WebRTC, muszą wymiana informacji łączności. Ponieważ warunki sieciowe mogą się różnić dependning od szeregu czynników, usługa zewnętrzna jest zwykle wykorzystywane do wykrywania ewentualnych kandydatów do łączenia się z każdym. Usługa ta nazywa ICE i używając do ogłuszania lub serwer TURN. STUN oznacza Sesja Traversal narzędzia dla NAT, i jest zwykle używany pośrednio w większości zastosowań WebRTC.

TURN (przemierzania Korzystanie z przekaźnika NAT) jest bardziej zaawansowane rozwiązanie, które wykorzystuje protokoły STUN i większość usług opartych WebRTC komercyjnego wykorzystania serwera zwrócić się o ustanowienie połączenia między rówieśnikami. WebRTC API obsługuje zarówno STUN i TURN bezpośrednio, i to jest zebrane pod pełniejszego wyrażenia Internet Connectivity Establishment. Podczas tworzenia połączenia WebRTC, zwykle dostarczają jeden lub kilka serwerów lodu w konfiguracji dla RTCPeerConnection obiektu.

sączyć ICE

Gdy RTCPeerConnection tworzony jest obiekt, podstawowe ramy korzysta z dostępnych serwerów ICE zebrać kandydatów do utworzenia złącz (ICE kandydatów). Impreza icegatheringstatechange na RTCPeerConnection sygnałów w jakim stanie jest zebranie ICE ( new , gathering lub complete ).

O ile jest to możliwe dla peer poczekać aż lód zgromadzenie jest kompletna, to zwykle dużo bardziej efektywne w użyciu techniki „strużka lodu” i przekazują każdego ICE kandydata do zdalnego peer, jak robi odkrycie. Pozwoli to znacznie skrócić czas konfiguracji dla łączności rówieśniczej i umożliwiają połączenia wideo, aby zacząć z mniejszymi opóźnieniami.

Aby zebrać ICE kandydatów, wystarczy dodać detektor dla icecandidate imprezy. RTCPeerConnectionIceEvent emitowany na tym słuchacza będzie zawierać candidate właściwość, która reprezentuje nowego kandydata, który powinien zostać przesłany do zdalnego peer (patrz SYGNALIZACJA).

 // Listen for local ICE candidates on the local RTCPeerConnection
peerConnection.addEventListener('icecandidate', event => {
    if (event.candidate) {
        signalingChannel.send({'new-ice-candidate': event.candidate});
    }
});

// Listen for remote ICE candidates and add them to the local RTCPeerConnection
signalingChannel.addEventListener('message', async message => {
    if (message.iceCandidate) {
        try {
            await peerConnection.addIceCandidate(message.iceCandidate);
        } catch (e) {
            console.error('Error adding received ice candidate', e);
        }
    }
});
 

połączenie ustanowione

Po ICE kandydaci są odbierane, powinniśmy oczekiwać, że stan naszego peer ostatecznie zmieni się w stanie połączonym. Aby to wykryć, możemy dodać do naszego słuchacza RTCPeerConnection gdzie możemy słuchać za connectionstatechange wydarzeń.

 // Listen for connectionstatechange on the local RTCPeerConnection
peerConnection.addEventListener('connectionstatechange', event => {
    if (peerConnection.connectionState === 'connected') {
        // Peers connected!
    }
});
 

RTCPeerConnection dokumentacja API