本篇是 TensorFlow 通信机制系列的第二篇文章,主要梳理使用 gRPC 网络传输部分模块的结构和源码。如果读者对 TensorFlow 中 Rendezvous 部分的基本结构和原理还不是非常了解,那么建议先从这篇文章开始阅读。TensorFlow 在最初被开源时还只是个单机的异构训练框架,在迭代到 0.8 版本开始正式支持多机分布式训练。与其他分布式训练框架不同,Google 选用了开源项目 gRPC 作为 TensorFlow 的跨机通信协议作为支持。gRPC 的编程和使用其实是相对复杂的,TensorFlow 为了能让 gRPC 的调用更加平滑,在调用链封装和抽象上面做了较多工作,甚至有些工作例如创建和管理 gRPC channel 涉及到了 GrpcSession 模块。从个人角度来看,利用 gRPC 进行 Tensor 通信的过程已经足够丰富,所以我们只针对 gRPC 传输 Tensor 过程进行梳理,至于涉及到 gRPC 管理方面的内容会在另一篇介绍分布式 Session 创建和管理的文章中集中梳理。
TensorFlow 中的通信机制 ——Rendezvous(二)gRPC 传输
2022-06-27 11:54:26详解|SRT编码器中Rendezvous模式详解
2022-06-27 11:51:54KILOVIEW最近发布SRT相关文章中,大家对caller模式和listener模式比较容易理解,近期收到很多客户反馈,对Rendezvous模式不是特别了解,下面将对Rendezvous模式进行详细介绍。
功能
两台设置Rendezvous模式的设备会共同协商,通过相同的UDP端口号建立一个SRT会话。
使用场景
两台设备所在的网络都有防火墙(或者路由器,功能等同),防火墙Outside接口是公网IP地址,但是没有防火墙的操作权限(即无法配置端口映射),如果防火墙设置了适当的工作模式,可通过Rendezvous模式建立SRT会话。
一旦完成SRT连接的建立,SRT源设备和SRT目标设备便开始交换控制信息,然后直接利用建立起来的SRT通道去传输数据。
完整SIP/SDP媒体协商概论-ICE初始offer发送详解
2021-07-06 14:43:17在前面的章节中,我们主要讨论了ICE概览,介绍了ICE的基本处理流程和候选地址配对的算法概论和轻量级ICE部署(Lite Implementations)的讨论。和前面介绍中讨论的SIP中offer的处理一样,在此文章中,笔者也将首先介绍ICE处理过程中初始offer的发送处理。因为轻量级的ICE部署场景不是RFC5245推荐的场景,本身协商也忽略了很多检查流程,所以笔者还是按照规范的的重点内容来讨论全部署场景(Full Implementations)中关于初始offer的处理,结尾部分将讨论轻量级ICE部署的场景和SDP解码。
完整SIP/SDP媒体协商概论-ICE初始offer发送详解
2021-07-06 14:41:44在前面的章节中,我们主要讨论了ICE概览,介绍了ICE的基本处理流程和候选地址配对的算法概论和轻量级ICE部署(Lite Implementations)的讨论。和前面介绍中讨论的SIP中offer的处理一样,在此文章中,笔者也将首先介绍ICE处理过程中初始offer的发送处理。因为轻量级的ICE部署场景不是RFC5245推荐的场景,本身协商也忽略了很多检查流程,所以笔者还是按照规范的的重点内容来讨论全部署场景(Full Implementations)中关于初始offer的处理,结尾部分将讨论轻量级ICE部署的场景和SDP解码。
WebRTC - ICE 过程简述
2021-07-06 14:38:291. ICE介绍
1.1.ICE 的角色
分为 controlling和controlled。
Offer 一方为controlling角色,answer一方为controlled角色。
1.2.ICE的模式
分为FULL ICE和Lite ICE:
FULL ICE:是双方都要进行连通性检查,完成的走一遍流程。
Lite ICE: 在FULL ICE和Lite ICE互通时,只需要FULL ICE一方进行连通性检查, Lite一方只需回应response消息。这种模式对于部署在公网的设备比较常用。
Webrtc delay-base-bwe代码分析(2): InterArrival模块
2021-07-06 14:24:42Webrtc delay-base-bwe代码分析(2): InterArrival模块
0. 参考文档
[1] google congestion control
[2] Rtp payload format for h264
1. 功能
该模块主要对到达的时间进行小范围内的统计、采样,并根据一定的时间间隔计算出对应的延迟、传输大小变化。
The arrival-time filter. The goal of this block is to produce an estimate m(ti) of the one way delay gradient. For this purpose, we employ a Kalman filter that estimatesm(ti) based on the measured one way delay gradient dm(ti) which is computed as follows:
dm(t(i) = (t(i) - t(i-1))-(Ti - T(i-1))
where Ti is the time at which the first packet of the i-th video frame has been sent and ti is the time at which the last packet that forms the video frame has been received.
从janus中学习webrtc的ice简单交换过程
2021-07-06 14:22:301. 简介:
本文通过web和janus进行实时音视频通信的Demo,结合rfc-5245来学习ice交换的过程。
2. 测试模型
本文测试模型为一个NAT内的web的客户端,向一个NAT内的janus服务器发起请求。
3. rfc 5245
本文只捡基础的一个流程进行分析,5245协议本身囊括的内容较多。(这里主要围绕2, 2.1, 2.2三段)。
WebRTC PeerConnection 建立连接过程介绍
2021-07-06 13:23:120x00 前言
WebRTC 中数据传输都是通过被称为 PeerConnection 的对象来完成的,PeerConnection 在可以传输数据前的建立过程相对于传统的 C/S 模式有略微差别,类似于 P2P 连接的建立过程,并且复用了传统的 STUN/TURN/ICE 架构的 P2P 实现方式。由于 WebRTC 支持 MESH/SFU/MCU 三种模式,使用 PeerConnection 概念的好处是可以同时兼容这三种模式,即使是像 SFU/MCU 这种非 P2P 的场景也同样使用 PeerConnection 来建立传输通道,不过针对 SFU/MCU 场景已经有一些优化方案,例如 ice-lite 。本文介绍了 P2P 和 SFU 场景中 PeerConnection 建立的过程。
P2P技术详解(三):P2P技术之STUN、TURN、ICE详解(转载)
2021-07-06 13:18:39内容概述
在现实Internet网络环境中,大多数计算机主机都位于防火墙或NAT之后,只有少部分主机能够直接接入Internet。很多时候,我们希望网络中的两台主机能够直接进行通信,即所谓的P2P通信,而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后,在进行P2P通信之前,我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透(NAT Traversal)。最常见的NAT穿透是基于UDP的技术,如RFC3489中定义的STUN协议。
STUN,首先在RFC3489中定义,作为一个完整的NAT穿透解决方案,英文全称是Simple Traversal of UDP Through NATs,即简单的用UDP穿透NAT。
在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具,而不是一个完整的解决方案,英文全称是Session Traversal Utilities for NAT,即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外,最大的区别是支持TCP穿透。
TURN,首先在RFC5766中定义,英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT,即使用中继穿透NAT:STUN的扩展。简单的说,TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果,异同点是TURN是通过两方通讯的“中间人”方式实现穿透。
ICE跟STUN和TURN不一样,ICE不是一种协议,而是一个框架(Framework),它整合了STUN和TURN。