我有一个可能会生成并发System.Threading.Tasks.Task个项目的进程。
为简化说明，我有一个主任务，以及其他子任务。
SubTask A - 从主任务接收传入的数据流（传入的字节流）。
AnonymousPipeStream（由主创建，然后传递给子任务的客户端管道句柄创建）SubTask B （进行中）不同 - 这需要具有主的双向数据流。
AnonymousPipeStream，但这只允许单向数据流。MemoryStream，但这不允许阻止（例如，在子任务中阻止Read()调用，直到父母有足够的数据可供使用）NamedPipe似乎是可能的（双向沟通），但考虑到沟通是在同一个过程中并且不需要在外部可见，这似乎有点过分。最后，我考虑创建一个TwoWayAnonymousPipe类（继承自PipeStream，并使用两个单向AnonymousPipeStream项目）
公开Stream对象的东西会很有用，因为子任务会调用一个期望传递给System.Net.Security.SslStream().AuthenticateAsClient()的API（Stream）。
问题：这似乎是解决问题的“合适”方法，还是我忽略了“更好”的现有解决方案？
注意：我感谢“更好”有多种解释 - 我希望“清晰，稳定，得到良好支持和记录”，不一定是“最快”
稍微加强一下解释：
NetworkStream（带有标头+有效负载的基于数据包的项目）System.Net.Security.SslStream的包装器，用于处理解码内部有效负载流和握手（可能分布在多个数据包上）System.Net.Security.SslStream有一个 AuthenticateAsClient 方法，需要双向Stream Task旨在允许加密任务与主NetworkStream处理任务“分开”运行。PipeStream超过MemoryStream的一个主要原因是，如果我们尚未从主程序中收到足够的片段，则会有内置的处理阻止Read()的能力/ strong>形成完整的SSL数据包。因此，（虽然我很欣赏TPL-Dataflow的好处），但我还不相信它对于这种特殊情况是理想的...主要的“目标”是将字节流包装成可阻塞的两个-way Stream（但允许卸载加密项并在后台运行）...
当前的研究项目（感谢所提供的反馈）