WebRtc重要概念

最新推荐文章于 2024-04-05 11:00:41 发布

Jalon007

最新推荐文章于 2024-04-05 11:00:41 发布

阅读量3.4k

点赞数 2

分类专栏： Android 文章标签： webrtc 通信框架

本文链接：https://blog.csdn.net/u010657219/article/details/54930705

版权

Android 专栏收录该内容

45 篇文章 2 订阅

订阅专栏

Signals

WebRtc底层库libjingle类与类之间的通信使用了信号和槽机制sigslot library.
信号和槽是一种非常简单的类与类之间的通用通信框架.通过如下方式实现:
- 发送信号类申明一个特定参数的signal.
- 监听类实现槽函数(solt)，槽函数必须和发送信号申明的参数一致(信号发送类和实现类可以是同一个类)。槽函数无返回值，并且类一定要继承sigslot::has_slots<>
- 监听者通过调用信号的connect方法，实现信号和槽的绑定。
- 信号和槽绑定之后，可以通过调用信号，从而直接调用槽函数(跟函数指针类似)

一个槽能和多个信号绑定。

Threads

总体来说libjingle分两大线程分别为signaling thread和 worker thread。signaling thread主要负责事件和状态， worker thread主要跟各种数据流相关。
为此libjingle也是煞费苦心，比如：

/*android\webrtc\src\talk\app\webrtc\peerconnectionfactory.cc*/
bool PeerConnectionFactory::Initialize() {
  RTC_DCHECK(signaling_thread_->IsCurrent());
  rtc::InitRandom(rtc::Time());

  default_allocator_factory_ = PortAllocatorFactory::Create(worker_thread_);
  if (!default_allocator_factory_)
    return false;
/*
  实际上就是在worker_thread_线程中调用了CreateMediaEngine_w方法,
  在libjingle库中有很多类似的用法
*/
cricket::MediaEngineInterface* media_engine =
      worker_thread_->Invoke<cricket::MediaEngineInterface*>(rtc::Bind(
      &PeerConnectionFactory::CreateMediaEngine_w, this));

  channel_manager_.reset(
      new cricket::ChannelManager(media_engine, worker_thread_));

  channel_manager_->SetVideoRtxEnabled(true);
  if (!channel_manager_->Init()) {
    return false;
  }

  dtls_identity_store_ = new RefCountedDtlsIdentityStore(
      signaling_thread_, worker_thread_);

  return true;
}

通常来说有如下规律：
- 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中转的形式，实现跨越防火墙的数据交换

如下图所示：
这里写图片描述