mesh

BLE MESH 学习 BLE MESH 是一种蓝牙（n:m）组网的技术。 本篇先介绍 BLE MESH 到使用 ESP32 的官方示例对其进行学习讲解。 后面会进一步学习 SIG 的 BLE MESH 协议和架构，以及 RTL8762C 使用。 一、 BLE 和 经典蓝牙简介 1.1 SIG 简介 蓝牙技术现如今由蓝牙技术联盟（Bluetooth special interest group，简称Bluetooth SIG）制定，后面称 SIG。SIG 负责发布维护蓝牙的通信规格和标准。 1.2 BLE 的诞生 SIG 在 2010 年发布了蓝牙4.0，第一次引入的 LE（Low Energy）模式，到后来 2014年发布蓝牙4.2 ，2016 年发布蓝牙5.0。其中 LE 模式常被称为 BLE (Bluetooth Low Energy，蓝牙低功耗)。 在蓝牙4.0 规格中，SIG 定义了四种蓝牙 controller 技术：BR，EDR，AMP 和LE，也就是说，蓝牙只有一种蓝牙，那就是 SIG 的蓝牙，而蓝牙技术本身包含四种类型：BR，EDR，AM 和 LE。 其中 LE 技术就是面向更低成本和功率消耗应用的，在物联网有更好的应用。相反地其他 BR、EDR、AM 等经典技术也就合称为经典蓝牙（BT）。 1.3 BLE 和经典蓝牙应用

文章关键词：背靠背测试、合法最小帧间隙、缓存区结构、吞吐量测试。 随着网络规模的扩大，大量的路由更新消息、频繁的文件传输和数据备份等操作都会导致数据在一段时间内急剧增加，甚至 达到该物理介质的理论速率。 为了描述此时路由器的表现，就要进行背靠背突发的测试。背对背测试 通过向被测设备发送具有合法最小帧间隙的突发包，确定被测设备在不丢包的情况下能够处理的最大包数目，以考察路由器接口对于突发数据的缓存能力。 具有不同类型的缓存区及分配策略的路由器，例如共享缓存区结构、输入缓存区结构、输出缓存区结构，和其他缓存区结构，必然具有不同的背对背的值， 背对背的值越大，路由器的缓存能能力就越强。 背对背测试与吞吐量测试都反映了路由器的数据包转发能力，但二者的测试“压力”不同，吞吐量的测试重在转发引擎的转发能力，而背对背测试重在接口缓存能力。 当路由器吞吐量不能达到最大理论值时，有必要进行背对背测试，尤其是必须传输对丢包很敏感的传输流（如视频流）的网络，对路由器进行背对背测试是非常有必要的。 对于有多种介质（如以太网、令牌环网和ATM等）且每一种介质有多个端口的被测设备，测试时需要考虑多介质混合、一对端口部分网状和全网状等情况，测试帧长度也要覆盖各种情况。这里我们以信而泰自主研发的Renix测试软件进行测试演示。 拓扑说明： DUT是一台Layer2交换机测试仪2个端口和交换机2个端口相连（千兆

前言 cesium 官网的api文档介绍地址 cesium官网api ，里面详细的介绍 cesium 各个类的介绍，还有就是在线例子： cesium 官网在线例子 ，这个也是学习 cesium 的好素材。 内容概览 1.基于cesium 实现地形图 Terrain 效果 2.源代码 demo 下载 本篇实现 cesium 加载地形图 Terrain 功能，效果图如下： cesium 支持地形图数据格式 Quantized-mesh ，Cesium团队提供的开发的格式 Heightmap，Google Earth Enterprise cesium 加载地形图类 CesiumTerrainProvider cesium 中添加地形数据，我们创建一个 CesiumTerrainProvider, 指定一个 URL 地址和一些配置的选项，然后讲它分配给一个 viewer.terrainProvider。在这个实例中，我们可以使用 createWorldTerrain 辅助功能创建一个 Cesium 世界地形。 核心代码： // Cesium动态叠加地形图 MapConfig.terrainObj = {url:"//assets.agi.com/stk-terrain/world",requestWaterMask: false ,requestVertexNormals: false

各位开发者好，白鹭引擎团队今天发布2020年最大的一次更新：Egret5.3版本。由于白鹭引擎团队在2019年已经针对部分开发者提供过内部的5.3.x 版本，所以本次更新的版本号为 5.3.5。 根据白鹭引擎 2018年以来的规划，版本号第二位为奇数位表示这个版本是抢先体验版而非稳定版，因此我们将在 Egret 5.3 系列版本中相对激进的引入新特性，但是在本次更新的5.3.5中我们还是优先保证现有开发者能直接升级至最新版本同时尽量不引入新的问题。 闲话少说，本次更新内容包含了四大部分： 1、引擎运行时改善； 2、支持发布到360PC小游戏； 3、Egret UI Editor 发布 1.9 版本； 4、Egret Inspector 发布 3.5 版本。 引擎运行时 [新增] 增加对 EgretPro 的适配，在 EgretPro 中可以无需修改直接使用该版本引擎； [新增] canvas 渲染模式增加对 Mesh 渲染的支持，使得 DraonBones 或 Spine 可以在 Canvas 模式下渲染网格动画； [新增] 增加 ttf 字体文件的支持； [修复] Rectangle 中 contains 与 containsPoint 对是否包括边界点的返回结果不同的问题； [修复] 显示对象与 mask 的角度为 90 度时，显示错误的问题； [修复] 微信浏览器下

关键词：RFC2544；时延测试；标记帧；储存转发时延；直通交换时延。 时延概述： 时延也常被成为延时（latency），是指 一个帧从源点到目的点的总传输时间，包括网络节点的处理时间和在传输介质上的传播时间， 其原理是发送帧时，带上时间戳（T1），发送到网络上，接收帧时，记录时间戳（T2），最后在接收方将2个时间戳比较（T2-T1），得到时延值。时延越大，说明设备处理数据包的速度越慢，因此时延也是考察被测设备的重要性能之一。 但是，通过测试直接得到这两个参数在工程实现上是非常困难的，因为在一个测试流中，每个帧的开始标志和结束标志都是相同的，通过记录输入帧的最后一位到达输入端口的时刻和输出帧的第一位出现在输出端口的时刻来计算延时几乎是不可能的，考虑到网络报文是一个不可分割的整体，整个报文的延迟是和报文中任意位的延迟是相等的，引入了标记帧方法来测试延迟。通过在报文中特定位置加入特殊标记（Tag），将记录输入帧的最后一位到达输入端口的时刻和输出帧的第一位出现在输出端口的时刻转化为记录网络设备接收带有标记的帧的时间和发送带有标记帧的时间，从而使延迟测试变得简单可行。 也就是说，网络设备的延迟是由测量带有标记帧的延迟得到的。为此必须要求带有标记的帧不能在传输过程中丢失，并且被转发的时候网络设备应该已经工作在稳定状态，即带有标记的帧不要出现在测试流的开输处

Large Pose 3D Face Reconstruction from a Single Image via Direct Volumetric CNN Regression 　　该文献采用一个新型的VRN网络对任意的面部姿势和表情的2D图片进行3D面部重建，并绕过3D可变模型的构造（在训练期间）和拟合（在测试期间）。 volumetric representation 　　文献中是通过CNN回归来预测3D面部的顶点，直接对所有的3D面部点进行预测的话不利于VRN的学习。该文献中将mesh转换为voxel,变成一个192*192*200的矩阵。这样就比较适合CNN。我们先看看mesh和voxel的区别：下面的第一张图是mesh，可以看出就是一个曲面；第二张是voxel，可以看出人脸是由很多个立方体构成的。 作者给出了voxel转成obj的脚本，运行出来是这样的： 这是一个封闭的曲面。这就有个问题了，由CNN预测出来的3D人脸的顶点是不固定的，也就是我们还需要进行一步对齐，将一个固定顶点的模板对齐到CNN预测出来的3D人脸。 mesh转voxel可以用binvox这个工具。 Volumetric Regression Networks(VRN) 　　该网络由两个Hourglass Networks构成（ HN网络 ），两个NH的结构类似，第二个NH对第一个NH的输出进行优化。

前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。 备注1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。 原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限： Service Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯； API Gateway： 负责将服务以 API 的形式暴露（给系统外部），以实现业务功能； 如上图所示： 从功能和职责上说： 位于最底层的是拆分好的原子微服务，以服务的形式提供各种能力； 在原子微服务上是（可选的）组合服务

客户在线教育应用，对实时视频互动要求较高，还要Web上实现微信视频效果，H5方便业务的接入和集成。针对业务要求，分析需求，我们总罗列下来： 1，全套Web实现（IOS,Android,PC兼容）。 分析：web实时视频支持rtmp,flv,webrtc，rtmp,flv是基于tcp实现，主要直播，延时不太可控，1-3秒左右，webrtc可以实现udp传输，低延时可控一些，兼容主要在IOS上，测试目前safira上，多轮验证后，选择WebRtc技术实现。 2，延时要低，延时越低越好。 分析：webrtc目前多方方案也有多种，Mesh，Sfu,MCU,比较分析，sfu要转发，mcu要混屏，延时稍高于Mesh,目前多方人数要求不高，最好确认选型Mesh开发。 3，多方互动，类微信展示。 分析：多方Mesh，协及多端浏览器版本，特别是兼容这块，和摄像头切换，最后针对浏览器匹配api,多轮测试后全套兼容目前平台 4，集成接口简单。 分析：网页调用，手机,PC,PAD一套，开发过程中全面调通，后端留有业务回调，集成调用都很方便。 最后总结： 目前webrtc已成为网页视频互动的标准，在业务集成上都很便捷，是视频业务必选的技术之一，Mesh在小量多方视频互动性能更优，现在业务集成度和效果，H5视频互动已能满足业务需要。 效果图： 测试地址： https://m.ovmeet.com:3000

随着互联网深入，视频互通互联的需求越来越多，近些年国家要进一步发展5G网络，手机等设备硬件也越来越好，对视频互通性，及时性，便捷性提出了新的需求。 1，H5-WEB接入，全平台web通用： a、在针对政企需求中，视频现在是硬性指标，但现有的系统90%以上是B/S系统. b、各种视频的APP多种多样，接口复杂，不适合接入。 c、对低延时互动需求越来越高，能视频通话，能多人互动。 选型确认：目前主流的rtmp,flash,hls,可以在web实现，但延时大，互动效果差， Webrtc的web接入成了首先，但由于IOS这块进展慢，各种限制，在实施中要处理几个难点，android-vp8<>ios-h264<>pc-vp8互通，这里难点是编码转换，目前ios的webrtc是h264编码，其它是vp8,融合平台要实现全通和自动转换编码。 2，rtsp,rtmp,sip,webrtc,转协议，网络监控头,H5视频端，PAD，手机，PC,SIP硬件，全接入 a、视频设备的种类多，各种老设备，老协议也需要兼容接入。 b、各种编码的格式，延时度，统一格式，响应转发。 c、早期企业的视频会议，直播设备，这里针对性兼容sip,rtsp,rtmp。 选型确认：做为互动协议肯定只能以webrtc为主，编码以h264，vp8两种，支持rtmp(可以兼容各大直播平台),sip分发，。难点是协议处理转换，大工程。

函数计算（Function Compute） ： 函数计算 是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地可靠地运行任务，并提供日志查询、性能监控和报警等功能。借助函数计算，您可以快速构建任何类型的应用和服务，并且只需为任务实际消耗的资源付费。 访问 PostgreSQL 数据库是指在函数计算中通过编写代码调用数据库驱动库通过 TCP 协议实现对数据库进行的插入、查询等操作。通常函数计算中运行的不同函数实例之间是不共享状态的，对于结构化的数据可以通过数据库的形式进行持久化以实现状态共享。由于用户函数运行在函数计算的 VPC 中，而用户的数据库运行在用户所属的 VPC 中，所以在函数计算平台访问数据库会涉及到跨 VPC 访问的场景，下面我们先来介绍一下其工作机制。 转存失败 重新上传 取消 工作机制 访问 PostgreSQL 的原理、工作机制与访问 Mysql 数据库完全相同，本文不再重复阐述，更详细的内容请参考 访问 Mysql 数据库 中的工作机制章节。 配置与函数编写 公共配置 创建专有网络VPC 登录 VPC控制台 。 参阅 VPC 搭建专有网络 创建VPC和交换机。 创建安全组 在 安全组控制台 新建安全组，点击 创建安全组 ，设置安全组名称，网络类型选择 专有网络