2016-03-17 5 views
6

Piszę moją pierwszą aplikację do połączeń peer-to-peer za pomocą WebRTC, a mój kod, aby zażądać kandydata na lód od peera, który wysyłam przez połączenie socket.io, uruchamia się 6 razy zamiast raz.Dlaczego moje żądanie kandydata na lód jest wykonywane 6 razy zamiast 1?

To jest bardzo mylące, ponieważ gdybym błędnie zaprojektował dużą pętlę żądania, oczekiwałbym nieskończonej liczby rekursji, a nie tylko 6 (8 onicecandidate zdarzeń). Czy ktoś może mi powiedzieć, dlaczego poniższy kod wygenerował 6 rekursji?

Oto obsługi wiadomości, to po prostu wysyła wiadomość socket.io kontrolowane przez składnię: Muveoo.Messenger.input('ice candidate request', data);

'ice candidate request' : function(data) { 
    console.log('Debug 10: Requesting Ice Candidate'); 
    socket.emit('ice candidate request', data); 
}, 

A oto kod, który obsługuje żądanie Ice Candidate, Nie należy mylić przez logikę if u bardzo bliskie, UID jest po prostu unikalnym identyfikatorem przypisanym do każdego klienta, aby zdecydować, kto powinien początkowo przedstawić ofertę.

if (Muveoo.RTC.connectedPeers[id].dataChannels[name].UID < Muveoo.RTC.connectedPeers[id].dataChannels[name].peerUID) { 
    Muveoo.RTC.connectedPeers[id].dataChannels[name].offerConnection(function() { 
     console.log('[Debug A]: Offering Connection'); 
     Muveoo.RTC.connectedPeers[id].dataChannels[name].pc.onicecandidate = function(evt) { 
      console.log('[Debug A]: onicecandidate Event Triggered.'); 
      if (evt.candidate) { 
       console.log('[Debug A]: Sending Ice Candidate Request.'); 
       Muveoo.Messenger.input('ice candidate request', { 
        target : id, 
        candidate : evt.candidate, 
        channel : name 
       }); 
      } 
     }; 
     Muveoo.RTC.connectedPeers[id].dataChannels[name].pc.ondatachannel = function(evt) { 
      console.log('got data channel'); 
      Muveoo.RTC.connectedPeers[id].dataChannels[name] = evt.channel; 
      Muveoo.RTC.connectedPeers[id].dataChannels[name].channel.onmessage = function(evt1) { 
       handleMessage(evt1.data); 

      }; 
      Muveoo.RTC.connectedPeers[id].dataChannels[name].channel.message = function(msg) { 
       Muveoo.RTC.connectedPeers[id].dataChannels[name].channel.send(JSON.stringify(msg)); 
      }; 
     }; 
     socket.on('session description', function(data) { 
      console.log('Debug 12: Session Description Received'); 
      Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].desc = new Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].sessionDescription(msg.desc); 
      Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].pc.setRemoteDescription(Muveoo.RTC.connectedPeers[data.target].dataChannels[data.name].desc); 
      if (Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].UID > Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].peerUID) { 
       /*They sent the sessionDescription first, so need an answer*/ 
       Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].pc.createAnswer(function(answer) { 
        /*The answer is this side's local description*/ 
        Muveoo.RTC.connectedPeers[data.target].dataChannels[data.channel].pc.setLocalDescription(answer); 
        var data = { 
         target : data.target, 
         description : answer, 
         channel : data.channel 
        }; 
        socket.emit('session description', data); 
       }); 
      } 
     }); 
    }); 
} 

A oto wynikowe logi aby pokazać, co się dzieje:

[Debug A]: Offering Connection 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 
rtc.js:101 [Debug A]: Sending Ice Candidate Request. 
messenger.js:91 Debug 10: Requesting Ice Candidate 
rtc.js:94 [Debug A]: onicecandidate Event Triggered. 

Dlaczego moja prośba Ice Kandydat strzelające 6 razy zamiast 1?

+0

Mam nadzieję, że to nie jest zbyt mylące, ale mój projekt przestrzeni nazw ma na celu umożliwienie wielu połączeń między wieloma kandydatami, jednocześnie oferując ekspozycję w różnych modułach, 'Muveoo.RTC.connectedPeers [id] .dataChannels [name]' - id odnosi się tylko do unikalnego Identyfikator przypisany każdemu klientowi podłączonemu w bieżącej sesji i istnieją nazwy kanałów danych wideo "wideo" i "audio". Wiem, że to źle wpływa na zmienną prywatność, ale jestem jedynym programistą aplikacji, więc zmienna prywatność nie jest w tym momencie moim celem. . –

Odpowiedz

0

One nie są żądań. Jesteś odpowiedzialny za wysłanie jak największej liczby kandydatów do egzaminu ICE, które WebRTC generuje drugiej osobie poprzez wybór sygnalizacji.

Ten projekt nazywa podtrzymujące ICE i przyspiesza negocjacje, nie musząc czekać na wszystkich kandydatów można znaleźć góry i wszczepiane do oferty/odpowiedzi, co może potrwać od kilku sekund, więc proszę te wiadomości ASAP, jak o to chodzi (już powinieneś już wysłać ofertę/odpowiedź do czasu lokalnego pożaru, tj. po odesłaniu z powodzeniem setLocalDescription).

Każdy kandydat to port IP +, do którego można dotrzeć z lokalnym klientem.

Jeśli wysyłasz tylko wideo (bez dźwięku) w lokalnej sieci LAN bez Internetu (lub nie określasz żadnego serwera STUN lub TURN), zobaczysz tylko dwóch kandydatów: w każdym kierunku. Na przykład.

candidate:0 1 UDP 2133252543 192.168.1.5 58078 typ host 
candidate:0 2 UDP 2133252542 192.168.1.5 51446 typ host 

Jeśli dodać serwer STUN, wtedy będziesz dodatkowo zobaczyć serwera refleksyjne kandydatów, to znaczy w jaki sposób jesteś osiągalny z zewnątrz zapory.

candidate:1 1 UDP 1686032863 69.102.28.57 60453 typ srflx 
candidate:1 2 UDP 1686032862 69.102.28.57 62432 typ srflx 

Wreszcie, jeśli dodać serwer kolei Pokochasz więc również zobaczyć przekaźnikowe kandydatów, które są do serwera TURN który przekaźnik danych w ostateczności (jeśli nie ma bezpośredniego połączenia między rówieśnikami można znaleźć):

candidate:2 1 UDP 1153102742 12.202.18.33 71321 typ relay 
candidate:2 2 UDP 1153102741 12.202.18.33 71432 typ relay 

Dodaj do tego dźwięk i liczbę kandydatów podwójnych.

Oto a fiddle do eksperymentowania.