ASP.NET Core SignalR 迟到的、隐藏在角落的 RawResult
一、概述
在 ASP.NET 或 ASP.NET Core 中,如果服务端得到一个 JSON 字符串(比如从 Redis 缓存中获取),我们可以通过 Content 方法或直接创建 ContentResult 对象来作为 Action 的返回值。
1 | var json = "{\"key\": \"value\"}"; |
1 | return new ContentResult |
而在 SignalR 中,在 ASP.NET Core 7.0 之前,对于一个 JSON 字符串只能先反序列化,否则 Web 前端得用 JSON.parse() 处理一次。
本文主要记录测试 RawResult 的结果。
在 ASP.NET Core Web API 中处理 Patch 请求
一、概述
PUT和PATCH方法用于更新现有资源。 它们之间的区别是,PUT 会替换整个资源,而 PATCH 仅指定更改。
在 ASP.NET Core Web API 中,由于 C# 是一种静态语言(dynamic 在此不表),当我们定义了一个类型用于接收 HTTP Patch 请求参数的时候,在 Action 中无法直接从实例中得知客户端提供了哪些参数。
比如定义一个输入模型和数据库实体:
1 | public class PersonInput |
再定义一个以 FromForm 形式接收参数的 Action:
1 | [HttpPatch] |
1 | curl --location --request PATCH 'http://localhost:5094/test/patch' \ |
如果客户端只提供了 Name 而没有其他参数,从 HttpContext.Request.Form.Keys 可以得知这一点。如果不使用 AutoMapper,那么就需要使用丑陋的判断:
1 | [HttpPatch] |
本文提供一种方式来简化这个步骤。
基于 pyannote.audio 实现 Speaker Identification(说话人识别)
一种有界队列(Bounded Buffer)的实现
一、概述
在有 CPU 和 GPU 参与的一种运算中,比如深度学习推理,CPU 需要预处理数据,然后交给 GPU 处理,最后 CPU 对 GPU 的运算结果进行后处理。
在整个过程中都是 FIFO,即数据 ABC 按顺序输入,也需要按 A’B’C’ 顺序输出。
如果采用同步阻塞的方式,在 CPU 预处理时 GPU 处于空闲状态,GPU 运算时 CPU 后处理处于空闲状态并且也不能进行后续数据的预处理。这样影响整体的吞吐。
期望是 GPU 运算时,CPU 可以同时进行数据预处理和后处理。这是典型的单生产者单消费者模式。
在两个线程之间传递数据时,为确保线程安全,可以在一个线程每次 malloc 或 new 申请内存,在另一个线程 free 或 delete。为了避免频繁的内存分配和释放,需要使用到内存池。
本文描述采用有界队列实现内存池,适用场景和限制:
- 需要把内存使用控制在一定范围内。
- 整个过程不允许丢弃数据。
- 单生产者和单消费者。即不会(也不允许)同时生产,不会(也不允许)同时消费。如果确实要多线程生产或多线程消费,本代码并不适用。
- 生产和消费之间线程安全。
mediasoup 3.9.10 worker 的编译及生成 xcodeproj 和 sln
mediasoup 3.9.10 worker 源码初步梳理
一、概述
Mediasoup 主要提供了 3 个库和 1 个 demo。
| 库名 | 说明 |
|---|---|
| mediasoup | 主要包含三部分。一是 worker 可执行程序,由 C++ 实现,是本系列分析的重点;二是 Node 库,由 TypeScript 实现;三是 Rust 库,和 Node 的主要不同在于它没有以进程方式而是以静态库方式使用 mediasoup-worker。 |
| mediasoup-client | Web 客户端库。TypeScript 实现。 |
| libmediasoupclient | Native 客户端库。C++ 实现。 |
| mediasoup-demo | 官方 Demo。 |
| Examples | 各种示例。 |
网络上对 mediasoup 的 Node.js 层——准确说是对官方的 mediasoup-demo 的源码分析比较多,对于 mediasoup-client 和 mediasoup-worker (之后简 worker) 等的源码详细分析相对较少。本人之前有将 GB28281 集成进 mediasoup 的想法并验证了可行性,以及使用 .Net 重新实现过 Node.js 层(含 mediasoup-client 和 mediasoup-demo),对 worker 的源码进行过比较粗略地浏览。最近基于想要弥补一些比较模糊的认知,并且 mediaoup 本身也在进化,故就再做了一次源码的梳理。
至于 mediasoup 是什么、能做什么、与其他 SFU 相较而言的优缺点、Demo 如何运行、为什么不用单一语言来实现等等讨论不是本系列关注的重点。
在 macOS 12.2.1(Apple M1)/Xcode 13.2.1(MacOSX12.1.sdk) 下编译 libmediasoupclient
Nginx server_port 变量对批量端口反向代理的简单应用两则
一、概述
有如下两种情况的 Nginx 端口映射:一是比如将 8001-8010 这 10 个端口映射到本机的 18001-18010 这 10 个 HTTP/HTTPS 服务上;二是反过来,比如将 10080,18001-18010 这 11 个端口映射到本机的 80,8001-8010 这 11 个HTTP/HTTPS 服务上。
当然,对于 HTTP 服务,用 iptables 也是能够实现的。但是要做同一个域名下的批量端口的 SSL 反向代理的话,最直接的方式是在 nginx.conf 中写多个 server 配置块。这样会导致 nginx.conf 的内容过多。
如果批量端口如上面描述的那样有规律可循,则可以通过 server_port 变量来简化 nginx.conf。