使用WCF包装现有连接流

我有一个双向连接的

流的两端，我想通过它进行一些通信。流背后的底层实现并不重要，我想在
流
级别工作

我不想为流实现我自己的通信协议，而是想使用所有现有的WCF功能，用一个双向（请求/响应+回调）WCF通信通道来包装现有的流

我的问题是，我该怎么做

更新：

我已经走上了实现自定义传输的道路。我已经开始工作了，但我还是不太满意

我已经实现了一个
IDuplexSessionChannel
来包装流，以及相应的
IChannelFactory
和
IChannelListener
，以及一个用于创建通道工厂的绑定元素。现在，我只是通过连接的流，最终在创建传输通道时将其传递到传输通道中

因此，我可以创建通过流访问服务的客户端代理，如下所示：

var callback = new MyCallback();
var instanceContext = new InstanceContext( callback );
var pipeFactory = new DuplexChannelFactory<IMyService>( instanceContext, new StreamBinding(clientStream),
                                                        new EndpointAddress("stream://localhost/MyService"));
var serviceProxy = pipeFactory.CreateChannel();

var callback=new MyCallback（）；
var instanceContext=newinstancecontext（回调）；
var pipeFactory=新的DuplexChannelFactory（instanceContext、新的StreamBinding（clientStream），
新端点地址（“stream://localhost/MyService"));
var serviceProxy=pipeFactory.CreateChannel（）；

我遇到的问题是，似乎WCF设置为使用
ServiceHost
通过
IChannelListener
创建频道的服务器端。在我的情况下，我已经有一个连接的流，我将无法监听更多的传入连接。我可以解决这个问题，但我更不愿意使用
ServiceHost
来创建频道的服务器端，因为我最终使用了很多晦涩难懂的样板文件和黑客来实现它

问题

因此，我正在寻找一种更好的方法来获取IDuplexSessionChannels，并在服务器端和客户端将其包装到通道代理中

或者可能是不需要
IChannelListener
的不同ServiceHost实现

实际上，这里的问题是我不想要一个单一的服务器，多个客户端的安排，我的WCF服务和客户端之间有1-1的关系。有没有正确的方法来实例化其中一个

换句话说，我想创建服务器端服务实例而不使用ServiceHost

在此阶段如有任何建议，将不胜感激。
请使用两端的客户端。不过，您需要仔细定义合同。如果在流的两端都有ClientA和ClientB，当ClientA发送请求时，ClientB会希望它看起来像它所定义的回调契约，反之亦然。
似乎您混淆了WCF服务主机和WCF服务实例的角色。WCF服务主机基于InstanceContextMode提供服务实例。这很好地解释了它的工作原理。如果没有ServiceHost提供WCF服务的实例，您就不可能拥有它。反过来，ServiceHost依赖于ChannelListener来管理其消息传递基础结构。如果没有它，您将有一个“聋子”ServiceHost:）因此，我试图做的是做
ServiceHost
所做的事情来创建
InstanceContext
和服务实例<代码>服务主机

在接受新的传入连接时必须执行此操作。我已经建立了连接，所以我想跳过听力部分。“这当然不是不可能的…？”马克对我来说，这就像是利用一条既有隧道，再修建一条隧道来容纳它。。。WCF不是为这种东西而建的。。。您认为使用WCF可以解决的现有流（您编写的流正在工作）的问题到底是什么？好的，我有一些通过一些定义良好的接口公开的进程内服务。我希望使用通过继承的管道流进行通信的子进程透明地重新实现这些。实际上，WCF将为我提供一种很好的方法来实现服务调用、故障契约等，而不必在管道上滚动我自己的消息传递子系统。我以前在C++中自己滚动过，但是我希望能从.NET中得到一些帮助。嗨，马克，你对此有什么进一步了解吗？我想做同样的事情来扩展对相同用例的使用。匿名管道，因为它们是正确的选择，但利用了WCF中的所有通信RPC基础设施。我将接受这个答案，因为我认为它可能是正确的（至少，它可以正常工作）。不过我还没试过，所以。