Signals

WebRtc底層庫libjingle類與類之間的通信使用了信號和槽機制sigslot library. 信號和槽是一種非常簡單的類與類之間的通用通信框架.通過如下方式實現: - 發送信號類申明一個特定參數的signal. - 監聽類實現槽函數(solt)，槽函數必須和發送信號申明的參數一致(信號發送類和實現類可以是同一個類)。槽函數無返回值，并且類一定要繼承sigslot::has_slots<> - 監聽者通過調用信號的connect方法，實現信號和槽的綁定。 - 信號和槽綁定之后，可以通過調用信號，從而直接調用槽函數(跟函數指針類似)

一個槽能和多個信號綁定。

Threads

總體來說libjingle分兩大線程分別為signaling thread和 worker thread。signaling thread主要負責事件和狀態， worker thread主要跟各種數據流相關。 為此libjingle也是煞費苦心，比如：

通常來說有如下規律： - OnSomeMethod，以on命名的函數表示是一個信號的槽函數。 - SomeMethod_w 以”_w”結尾的函數表示此函數將在worker thread線程中運行 - SignalSomeName 信號的申明，可以調用槽函數

Transports, Channels, and Connections

每個P2PTransportChannel代表本地和遠程鏈接的數據通道。Channel是一個為了健壯性和性能而抽象出的一個概念。P2PTransportChannel管理許多的Connection對象，而每一個Connection對象都表示一個特性的鏈接類型比如UDP,TCP,RELAY ,etc。Connection實際上又封裝了一對對象，分別是Port的子類和一個地址(an address)。Port的子類代表本地的鏈接，an address表示遠程鏈接。如果某個特定的connection斷開了，P2PTransportChannel將會瞬間切換到另一個最佳鏈接. 下圖從一個較高的層次顯示P2P鏈接的數據流動形式： libjingle 應用在跟遠程端協商建立鏈接時，本地端會創建一系列的潛在接入端，也稱為candidates，被Port對象封裝的本地candidates是由PortAllocator子類分配。本地Port對象要么在CreatOffer時被創建，要么在接受到遠程的請求后創建(也就是在Answer期間)。遠程端P2PTransportChannel收到offer請求，將會創建一個Connection對象封裝遠程candidate和本地Port.本地端P2PTransportChannel收到Answer，也會創建一個Connection對象封裝遠程candidate和本地Port。

P2PTransportChannel創建和管理多個connection對象，實時第評估每個connection的性能，實時選擇性能最優的connection作為當前傳輸通道。

上圖沒有畫出P2PTransport，P2PTransport是整個P2P系統的頂層，負責創建銷毀，和監控P2PTransportChannel對象，但是不負責實際的數據傳輸。真正負責數據傳輸的是VoiceChannel，VideoChannel，DataChannel ，最終都是通過P2PTransportChannel實現數據的傳輸。

Candidates

libjingle最強大的功能在于能夠跨越防火墻和NAT建立鏈接。libjingle使用ICE協議穿透防火墻，首先libjingle準備跟遠程端建立鏈接時將會產生一系列潛在的本地端口地址供遠程端鏈接。這些潛在的地址稱之為Candidate.Candidates就是ip:port對，本地端和遠程端依據Ip:port對就能建立p2p鏈接。libjingle為穿透NAT或者防火墻，發現能夠供遠程端鏈接的candidates提供了健壯的機制。 為了盡可能的為遠程端提供共鏈接的Candidate，libjingle產生如下三種本地接入端： 1. Local IP addresses :本地的ip地址，其他在共享局域網的遠程端可以訪問這個地址 2. Global addresses:這是跨越防火墻/NAT的外部地址。如果網關是NAT設備，libjingle使用STUN服務器將NAT綁定到本地端并且向外暴露internet地址.這個地址供外部的遠程斷鏈接 3. Relay server addresses:接近8%的客戶端不能按照上面的兩種方式建立鏈接，需要通過relay server中轉的形式，實現跨越防火墻的數據交換

如下圖所示：