Should I use WCF to implement a given binary network protocol?

I have a client device (POS handheld) which communicates via TCP/IP or RS232 with it's server. The protocol is a given binary format, which I cannot change. I have to implement a server for that device. My impression is, that WCF would be a better choice than implementing anything by hand. But because it would require quite some time to give it a try, I would like to ask for advice whether it's a good idea and if it's possible to fine tune WCF to such a level of detail.

开发者_如何学Python

I found some questions which are similar to mine, but in those cases the OP had always full control over client and server. That's not the case for my scenario.

If WCF is a good idea - which I assume - some starting points would be very appreciated. Most documentation focus on SOAP, REST, ... and not on the lower levels I would have to work on.

---

Having worked with WCF for many years (and liking it), I don't think it's the best option for your needs. As Phil mentioned, it's sweet spot is around web services, not low level communication. To implement that in WCF, you'd need to write a custom transport, which, as with almost all of the low-level (channel programming), involves a lot of code. This transport would need to use sockets to understand the device protocol, and you'd need to somehow convert the messages from the protocol into WCF messages.

If the protocol is simple, I think that a "pure" socket based implementation would be the best way to go. The socket handling code (to communicate with the device) would be needed in a WCF solution anyway, but you can create your own message types instead of having to conform to a (rather SOAP-friendly) message protocol used by WCF.

One advantage that you'd have if you were to go all the way and implement the custom WCF transport which "talks" that protocol would be if you were to expose it to many different people who are already used to a WCF-way of implementing services - you'd have to bear the initial (very high) cost of writing a WCF transport, but later on people can write services for that device using the nice contract model that WCF provides.

---

WCF has quite a learning curve as is, and if you need to be customizing lots of very low-level things, the curve will be steeper.

Also, the reason WCF was created was to allow the developer to not worry about lower level implementation details. It seems like you want the best of both worlds, which means you will probably be spending most of your time fighting WCF to get it to work how you want.

Disclaimer: While I have a basic understanding of WCF, I am not an expert and I could be wrong.