Pipelines - .NET中的新IO API指引(三) 边看边记
2021-07-02 13:08
标签:ref amp 应用程序 利用 sequence 领域 个人 sockets 默认 Pipelines - .NET中的新IO API指引 作者 marcgravell 原文 此系列前两篇网上已有的译文 Pipelines - .NET中的新IO API指引(一) Pipelines - .NET中的新IO API指引(二) 关于System.IO.Pipelines的一篇说明 System.IO.Pipelines: .NET高性能IO 本篇不是翻译,边看边译边记而已。 System.IO.Pipelines 是对IO的统一抽象,文件、com口、网络等等,重点在于让调用者注意力集中在读、写缓冲区上,典型的就是 IDuplexPipe中的Input Output。 可以理解为将IO类抽象为读、写两个缓冲区。 目前官方实现还处于preview状态,作者使用Socket和NetworkStream 实现了一个 Pipelines.Sockets.Unofficial 作者在前两篇中提到使用System.IO.Pipelines 改造StackExchange.Redis,在本篇中作者采用了改造现有的SimplSockets库来说明System.IO.Pipelines的使用。 文章中的代码(SimplPipelines,KestrelServer )
Pipelines - .NET中的新IO API指引(三) 边看边记 标签:ref amp 应用程序 利用 sequence 领域 个人 sockets 默认 原文地址:https://www.cnblogs.com/cerl/p/9925879.html## SimplSockets说明
+ 可以单纯的发送(Send),也可以完成请求/响应处理(SendRecieve)
+ 同步Api
+ 提供简单的帧协议封装消息数据
+ 使用byte[]
+ 服务端可以向所有客户端广播消息
+ 有心跳检测等等## 作者的改造说明
### 对缓冲区数据进行处理的一些方案及选型
1. 使用byte[]拷贝出来,作为独立的数据副本使用,简单易用但成本高(分配和复制)
2. 使用 ReadOnlySequence
3. 作为2的扩展方案,将数据载荷的解析处理代码移至类库中(处理ReadOnlySequence
4. 通过返回Memory
5. 一个妥协方案,返回一个提供Memory
作者认为,设计一个通用的消息传递Api时,方案5更为合理,调用方可以保存一段时间的数据并且不会干扰到管道的正常工作,也可以很好的利用ArrayPool。如果调用者没有使用using也不会有什么大麻烦,只是效率会降低一些,就像使用方案1一样。
但是方案的选择需要充分考虑你的实际场景,比如在StackExchange.Redis 客户端中使用的是方案3;在不允许数据离开请求上下文时使用方案2.。
一旦选定方案,以后基本不可能再更改。
public interface IMemoryOwner
private sealed class ArrayPoolOwner
+ 从ArrayPool借出的数组比你需要的要大,你给定的大小在ArrayPool看来属于下限(不可小于你给定的大小),见:ArrayPool
+ 归还时数组默认不清空,因此你借出的数组内可能会有垃圾数据;如果需要清空,在归还时使用 ArrayPool
增加 IMemoryOwner
这里的想法是通过IMemoryOwner
void DoSomething(IMemoryOwnerbyte> data){
using(data){
// ... other things here ...
DoTheThing(data.Memory);
}
// ... more things here ...
}
+ 不要把data.Memory 单独取出乱用,using完了就不要再操作它了(这种错误比较基础)
+ 有人会用MemoryMarshal搞出数组使用,作者认为可以实现一个 MemoryManager
---- 作者也挺纠结(周道)的 :)。
public static IMemoryOwner
### 基本API
服务端和客户端虽然不同但代码有许多重叠的地方,比如都需要某种线程安全机制的写入,需要某种读循环来处理接收的数据,因此可以共用一个基类。
基类中使用IDuplexPipe(包括input,output两个管道)作为管道。public abstract class SimplPipeline : IDisposable
{
private IDuplexPipe _pipe;
protected SimplPipeline(IDuplexPipe pipe)
=> _pipe = pipe;
public void Dispose() => Close();
public void Close() {/* burn the pipe*/}
}
+ 有许多移动的部分
+ 与“pipelines”有些重复
+ 不一定时同步的
+ 调用方可以单纯的传入一段内存数据(ReadOnlyMember
+ 先假设读、写分开(暂不考虑响应)protected async ValueTask WriteAsync(IMemoryOwnerbyte> payload, int messageId)//调用方不再使用payload,需要我们清理
{
using (payload)
{
await WriteAsync(payload.Memory, messageId);
}
}
protected ValueTask WriteAsync(ReadOnlyMemorybyte> payload, int messageId);//调用方自己清理
返回值使用ValueTask因为写入管道通常是同步的,只有管道执行Flush时才可能是异步的(大多数情况下也是同步的,除非在管道被备份时)。### 写入与错误
首先需要保证单次写操作,lock在此不合适,因为它不能与异步操作很好的协同。考虑flush有可能是异步的,导致后续(continuation )部分可能会在另外的线程上。这里使用与异步兼容的SemaphoreSlim。
下面是一条指南:**一般来说, 应用程序代码应针对可读性进行优化;库代码应针对性能进行优化。**
以下为机翻原文
> 您可能同意也可能不同意这一点, 但这是我编写代码的一般指南。我的意思是,类库代码往往有一个单一的重点目的, 往往由一个人的经验可能是 "深刻的, 但不一定是 广泛的" 维护;你的大脑专注于那个领域, 用奇怪的长度来优化代码是可以的。相反,应用程序代码往往涉及更多不同概念的管道-"宽但不一定深" (深度隐藏在各种库 中)。应用程序代码通常具有更复杂和不可预知的交互, 因此重点应放在可维护和 "明显正确" 上。
基本上, 我在这里的观点是, 我倾向于把很多注意力集中在通常不会放入应用程序代码中的优化上, 因为我从经验和广泛的基准测试中知道它们真的很重要。所以。。。我要做一些看起来很奇怪的事情, 我希望你和我一起踏上这段旅程。
private readonly SemaphoreSlim _singleWriter= new SemaphoreSlim(1);
protected async ValueTask WriteAsync(ReadOnlyMemorybyte> payload, int messageId)
{
await _singleWriter.WaitAsync();
try
{
WriteFrameHeader(writer, payload.Length, messageId);
await writer.WriteAsync(payload);
}
finally
{
_singleWriter.Release();
}
}
通过两个问题进行重构
- 单次写入是否没有竞争?(无人争用)
- Flush是否为同步protected ValueTask WriteAsync(ReadOnlyMemorybyte> payload, int messageId)
{
// try to get the conch; if not, switch to async
//writer已经被占用,异步
if (!_singleWriter.Wait(0))
return WriteAsyncSlowPath(payload, messageId);
bool release = true;
try
{
WriteFrameHeader(writer, payload.Length, messageId);
var write = writer.WriteAsync(payload);
if (write.IsCompletedSuccessfully) return default;
release = false;
return AwaitFlushAndRelease(write);
}
finally
{
if (release) _singleWriter.Release();
}
}
async ValueTask AwaitFlushAndRelease(ValueTask
1. _singleWriter.Wait(0) 意味着writer处于空闲状态,没有其他人在调用
2. write.IsCompletedSuccessfully 意味着writer同步flush
3. 辅助方法 AwaitFlushAndRelease 处理异步flush情况
-------------------------------------------------------------------------------------
### 协议头处理
协议头由两个int组成,小端,第一个是长度,第二个是messageId,共8字节。void WriteFrameHeader(PipeWriter writer, int length, int messageId)
{
var span = writer.GetSpan(8);
BinaryPrimitives.WriteInt32LittleEndian(
span, length);
BinaryPrimitives.WriteInt32LittleEndian(
span.Slice(4), messageId);
writer.Advance(8);
}
public class SimplPipelineClient : SimplPipeline
{
public async Task
protected async Task StartReceiveLoopAsync(CancellationToken cancellationToken = default)
{
try
{
while (!cancellationToken.IsCancellationRequested)
{
var readResult = await reader.ReadAsync(cancellationToken);
if (readResult.IsCanceled) break;
var buffer = readResult.Buffer;
var makingProgress = false;
while (TryParseFrame(ref buffer, out var payload, out var messageId))
{
makingProgress = true;
await OnReceiveAsync(payload, messageId);
}
reader.AdvanceTo(buffer.Start, buffer.End);
if (!makingProgress && readResult.IsCompleted) break;
}
try { reader.Complete(); } catch { }
}
catch (Exception ex)
{
try { reader.Complete(ex); } catch { }
}
}
protected abstract ValueTask OnReceiveAsync(ReadOnlySequencebyte> payload, int messageId);
- TryParseFrame 读出缓冲区数据,根据帧格式解析出实际数据、id等
- OnRecieveAsync 处理数据,比如对于回复/响应的处理等
- reader中的数据读出后尽快Advance一下,通知管道你的读取进度;private bool TryParseFrame(
ref ReadOnlySequencebyte> input,
out ReadOnlySequencebyte> payload, out int messageId)
{
if (input.Length 8)
{ // not enough data for the header
payload = default;
messageId = default;
return false;
}
int length;
if (input.First.Length >= 8)
{ // already 8 bytes in the first segment
length = ParseFrameHeader(
input.First.Span, out messageId);
}
else
{ // copy 8 bytes into a local span
Spanbyte> local = stackalloc byte[8];
input.Slice(0, 8).CopyTo(local);
length = ParseFrameHeader(
local, out messageId);
}
// do we have the "length" bytes?
if (input.Length 8)
{
payload = default;
return false;
}
// success!
payload = input.Slice(8, length);
input = input.Slice(payload.End);
return true;
}
代码很简单,主要演示一些用法;
辅助方法static int ParseFrameHeader(
ReadOnlySpanbyte> input, out int messageId)
{
var length = BinaryPrimitives
.ReadInt32LittleEndian(input);
messageId = BinaryPrimitives
.ReadInt32LittleEndian(input.Slice(4));
return length;
}
OnReceiveAsync
protected override ValueTask OnReceiveAsync(
ReadOnlySequencebyte> payload, int messageId)
{
if (messageId != 0)
{ // request/response
TaskCompletionSource
到此为止,其余部分主要是一些服务端和其他功能实现及benchmark。。。
文章标题:Pipelines - .NET中的新IO API指引(三) 边看边记
文章链接:http://soscw.com/essay/100798.html