Nicholas Allen posted a while back a short entry on the assymetries between channel factories (send side) and channel listeners (receive side) in Windows Communication Foundation. I've been revisiting some of his posts while working on my custom channel, and this one seemed pretty fundamental.
The lifetime tie between channel factories and its output channels doesn't cause me problems. Actually, for my current work I don't really care about it because this is done purely to ease the cleanup of resources. Since channels will usually be tied to possibly different URLs and will likely not share the same network/transport connection, this is not usually a problem (and even if they did, it would still not be a problem).
However, things are quite different for channel listeners and input channels. As Nicholas clearly states, the lifetime of the channels is not to be tied to the specific channel listener that created them, so closing the channel listener should not cause any open channels to be closed or stop working. In general terms, if you have a transport where WCF will actually open connections (instead of receiving connections, like in my case), then it means the connection cannot be owned by the channel listener and instead must be owned by the channel itself, which means that channels cannot longer share connections unless I'm willing to do a lot of extra work (like reference counting it and doing some nasty fault handler).
Will I do that extra work? Not likely. In my specific case, my transport will pretty much be limited to having a single input channel opened at a time per channel listener, so adding this would not really benefit me. Furthermore, if I did the work to support sharing connections here, it would make it impossible for me to support ListenUriMode.Unique. The reason is that the listen Uri (unique or not) is tied to the channel listener, not the actual channel (which is a pretty big deal) and also because of how the protocol works. If I was sharing connections there would be no way for me to share a unique Uri between multiple input channels.
BTW, unique listen Uris are a feature I'm pretty interested in supporting in my custom channel as the protocol I'm working with has some explicit support for this built in that enables a number of very interesting scenarios.
