I have a mobile platform that I am trying to write some communications code on.
The platform provides a proprietary communication mechanism that is based on standard socket functions. Basically, the platform's socket API looks exactly the same as the standard Windows Socket API, except with a prefix on each of the functions.
I would like to use WCF to abstract the complexities of the Sockets API away from my consuming applications, but am having a hard time finding resources that adequately describe all the pieces that would need to be coded.
Can anyone recommend a good starting place, or provide a description of what would be necessary to write a custom Socket based Transport for WCF? Ideally, I'd like to be able to use HttpBinding over this transport mechanism.
Thanks!
I put together a list of some resources for writing a WCF transport channels which might be useful. Not all links are still active, unfortunately, but most are and there's some useful stuff in there.
I also put a short introduction to how some of the pieces fit together which might help a bit.
Something I don't quite get in your question: You mention that you want to run the HttpBinding on top of your transport. Do you mean you want to use the WCF http transport channel on top of your custom socket-like API instead of the regular windows sockets API?
If so, then no, that won't work for various reasons. One of them is that the bindings and channels are not really that directly tied together, Instead the binding definition (i.e. which binding elements are included in it) controls how the channel stack is created at runtime for your service/client.
So basically, when writing your custom transport channel, you will create your own custom TransportBindingElement-derived class that you can use in a custom binding to use your own transport channel instead of one of the default ones (like HttpTransport). However, notice that a transport channel is, anyway, the bottom of the channel stack (i.e. there's nothing underneath it), so you can't layer the HttpTransport on top of your custom transport anyway (even if the API limitation was not there).
In other words, if you want to speak HTTP, you'll need to bake the HTTP stuff into your custom channel implementation. However, nothing prevents you from using the rest of the default basic/ws http bindings on top of your own channel, provided you expose the right channel shapes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With