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.
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.
Related
I want to create a simple application in C# that sits between an existing TCP client and server, both legacy systems. Most of the time the application will simply pass messages from the client to the server and back again without modification. In one, maybe two cases, when it sees certain data from the client, it will modify this data slightly before passing it onto the server. It will not change the length of the data. It will not change the response from the server. How do I implement this in C#?
After much Googling, I found some suggestions, (some being an understatement!). There seems to be a multitude of way to implement a socket server in C# and no single, standard way, For example:
Kerry Jiang's SuperSocket.
Craig Baird's Code Project C# TCP Server.
Microsoft's own Asynchronous Server/Client Socket examples.
StackOverflow's own discussion on High performance TCP server in C#.
Any many, many more.
All in all quite a bewildering amount of information! It all seems overly complicated and total overkill for my use. I first thought of doing this in WCF, where all the underlying complexity is handled for me but apparently it's not possible (or very difficult) to do in WCF. Is there some way to implement what I want without going into all this complexity? Any 3rd party library or component that would simplify this implementation? Alternatively, maybe there is a hardware device that would allow me to this? Over to you.
I have been researching whether or not to use WCF for a new project we are going to be working on.
Basically the only reason which will prevent us from using it is the new project must be able to communicate with a legacy server which talks via .Net's TcpClient class with binary messages.
I am wondering if I can write a custom binding perhaps to send and receive messages from the server. I have managed to find that I can write custom bindings and encodings. But I am not sure if I can read messages as bytes and not soap messages.
One possible solution I thought of is to write a custom encoding which will transform the bytes into soap messages and vice versa. But I have not checked up on this or thought it through much.
Jason,
I'd suggest (not sure if this is an answer but I can't post comments, sorry),
you rather go with either a full sockets or a full WCF solution (meaning both client and the server).
Given you have a legacy server with via sockets - it's much easier to make a sockets client with some custom-protocol you have, and parsing, basic error handling etc.
...and you'll get it to be faster too (not sure what's the purpose, nature of the app and communication you're having with the server, or do you need some other WCF features etc.).
See this thread which is more or less your case...
WCF TCP client with Java Socket server on custom XML messages
...basically, you'd need to write a transport channel - which would again pretty much have to support everything that you'd need it to do for a 'sockets-only' client + extra work and layers.
That normally only makes sense if you're
a) going to reuse that for later on development, so e.g. you could just plug-in that solution for different servers or if you have many developers and large code base etc. (if you don't, making a sockets solution a separate lib and reusing is still easier) or
b) or you need some specific feature that ain't easily reproducible 'by hand and sockets' - still to support any of that you'd have to wrap it up pretty thoroughly anyway, or...
c) some 3rd party lib - that I'm not aware of for such cases (usually this falls into a 'too custom' work),
hope this helps some
Not sure if you've seen Carlos Figueira's series of posts on WCF extensibility but they're well worth a read if you want to understand what's possible and how to go about doing it.
http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx
There is an example of a custom TCP based binding for JSON-RPC that you may be able to use a basis for a new transport binding in your case.
http://blogs.msdn.com/b/carlosfigueira/archive/2011/12/08/wcf-extensibility-transport-channels-request-channels-part-1.aspx
I am implementing a WCF service which will be used (in part) within a private LAN.
I will be using netTcpBinding and would like to implement some form of security on the communications, more specifically, it is important that the data be encrypted so that (for example) nobody could view the data being transferred across the network.
I don't believe Windows authentication will be appropriate as the end user may not maintain their windows logins and roles rigorously enough to use them as authentication. Am I right in thinking this would make it inappropriate? Please correct me if I'm wrong.
My question is, what is the simplest way to implement encryption in a WCF service using the netTcpBinding? particularly when Windows credential type is not available.
I have tried experimenting with certificates (generating my own using makecert) but there is a distinct lack of tutorials and documentation describing how to do this from start to finish using TCP and hosting the service in something other than IIS. A lot of them talk you through how to generate the certificates in detail (and no two of these tutorials are exactly the same in this regard) and finish by saying something like
use these to sign the service and client
... well unfortunately that is the process I need a little more clarification on!
Generally the certificates solution seems to be over the top and a little too much just to acheive encrypted data!
Any help or corrections in any assumptions I might have made would be really appreciated.
Following the discussion in the comments...
In my experience (and I've done lots of serialization/WCF work) the performance "benefit" of NetTcpBinding (and NetDataContractSerializer) is largely mythical. I have never seen a significant difference - and often vanilla http bindings are faster.
I would switch to BasicHttpBinding over SSL which is trivial to setup and is secure.
If you want improved performance etc, I would switch serializer to something like protobuf-net (disclosure: I'm the author). This does have easily demonstrated performance advantages, and works nicely inside WCF (just a change to a config file), especially over BasicHttpBinding (with an extra boost if you enable MTOM message-encoding, since it is a binary format).
Personally, I never use NetTcpBinding; as mentioned, the performance is questionable, and it gets you dependent on things that won't work in basic-http if you find you need WAN access.
Summary: I need to know if there is an existing light-weight implementation of REST+JSON in .NET world which does not use WCF. If not, I am looking for some folks who would be interested to start a joint venture for an Open Source project.
I do not know about you but I was a big fan of WCF when it came out and I praised its design for its modularity and extensibility. However, as I used it more and more often, fundamental issues started to come into light to the point that I now feel it has to be scrapped and redesigned. That seems to be a big statement but I believe these are major issues:
First of all, WCF internally uses SOAP for message which means if the transport message is not SOAP, we incur the cost of transforming to and back from SOAP for every call. This is expensive and time consuming.
Transforming the outgoing message requires "plugging in" a message inspector and "stealing" the message. As the name implies, this is an inspector (must be used for inspection and logging) so using that for changing the message is frankly a hack.
It was design according to WSDL and the world has changed so much since 2001. Implementing REST also requires stealing the message. WCF was designed according to WSDL and not REST.
Channel stack is unnecessarily heavy.
The main stack is protocol agnostic. This is not a advantage, it is a fundamental flaw. As you know, access to a lot of protocol level information was added later because was impossible to implement some important user scenarios. For example, client’s IP address in TCP was not accessible and added later (now accessible using perationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name])
Interoperability with other platforms can be an issue.
Now it seems that a lot of designs are moving towards simplicity of JSON and REST. I just love their simplicity and I can see my washing machine consuming JSON in 5-10 years and hosting a REST service! I believe their implementation in .NET was a hack and we seriously need a very light weight and simple framework (because these are simple and light weight) to host REST+JSON services inside and outside IIS. I hope such a framework exist but if not, I am really eager to get something going with a number of like-minded folks.
So what do you think? Does such a framework exist? If not, is anyone interested?
MVC that spits out JSON instead of HTML seems like a possibility. You have the freedom to either use the JsonDataContractSerializer or JSON.Net to serialize your datacontracts.
Take a look at OpenRasta. It looks like it addresses many of your concerns.
If you really don't want to use IIS, you can implement your own HTTP listener process. This let's you write your own standalone application to respond to HTTP requests (which may be run as a service if you so desire) without any of the overhead of IIS, WCF or any other container process framework. Your process would live on top of the HTTP.sys functionality exposed by Windows, and exposed by the .Net framework through the HttpListener class.
Take a look at http://msdn.microsoft.com/en-us/library/system.net.httplistener.aspx
Note that you will need to write your own infrastructure for matching incoming requests and dispatching them to corresponding handlers (the equivalent of ASP.Net MVC's UrlRoutingModule/RouteTable.Routes/MvcRouteHandler), and you will need to flow the HttpListenerContext everywhere in order to examine the incoming request and complete it. But this gives you the ultimate in flexibility in what you can do.
And it certainly performs - I have benchmarked a basic HttpListener implementation on a standard desktop-class machine at over 3000 requests served/second, so the framework itself will not hold you back.
There is MicroRest, an open source project I started a while. Here's the blurb I wrote:
MicroRest is a tiny REST framework - 5 classes, around 500 lines of code. All output is JSON. It allows you to add REST capabilities to your ASP.NET applications without needing to go through the huge ugly mess of WCF rest (which doesn't provide 'clean' URLs in 3.5). It also allows you to use POCOs (and complex objects in some cases) inside your REST methods, where WCF restricts you to using ints and strings
Contributions are very welcome - it does rely on System.Web.Routing right now, so needs Cassini/IISExpress as an embedded web server. I'm looking at writing a custom route parser so it can move to Kayak as some point.
what is the diff, advantage and disadvantage between remoting and socket... which is best way for Server-Client functionality....
Sockets are raw binary streams between two endpoints. You would need to wrap your own RPC (etc) layer to process the messages, and deal with a lot of infrastructure code. However, since they are so close to the metal this can be very, very efficient. It is not tied to any specific architecture, as long as both ends talk the same message format. Tools like protobuf-net can help you construct binary messages for streams (rather than rolling your own serialization code).
Remoting is a .NET specific tool, and is very brittle re versioning. I wouldn't recommend remoting for client/server - use things like WCF instead.
WCF is a more flexible comms stack - a lot of power and complexity, but arguably a bit of bloat too (xml, complex security etc). It is data-contract based, so roughly open (client/server can be different), but still a bit .NET focused.
edit For info, protobuf-net provides an RPC stack too; at the moment there is only an HTTP implementation provided, but at some point I'll add raw TCP/IP.
Direct socket manipulation can give you more power, flexibility, performance, and unfortunately complexity when compared to Remoting or WCF. However, if you need the benefits of low-level TCP/IP, such as non-blocking IO and custom protocols, tools such as Ragel and frameworks like Mina can ease the complexity burden. I recommend trying the higher-level APIs like WCF first and only use direct sockets if these don't meet your needs.
I second most that Marc Gravell wrote - specifically remoting and internal serialization are "easy" but are very easy to break and often do not scale well to a public network (I'm not that familiar with .net remoting, but I guess it needs a well known registry service which is often problematic when going out of the clean lab environment).
Implementing a standard or even roll-your-own RPC is harder but safer in the long run: you do not have problems with code revisions (or they are easier to control), scaling is fully controlled by your own code, and its easy to develop components using various technologies.
There are many many many tools that help you easily build RPC mechanisms over sockets, but I really like to use plain old HTTP - get a simple HTTP embedded server running inside your server process and your client just needs to have an HTTP client to send messages. If you develop your own simple RESTful call semantics (instead of using some bloated message format like SOAP or XML-RPC), then there is really almost nothing to do :-)
I would say that choosing between sockets and remoting you better consider on what type of application you are developing. Sockets are definitely for your own protocol implementations, low level programming and the only way to go if you have to communicate to the other tcp/ip applications. Remoting is a preffered way to develop new .NET communication applications, where you don't need to come down to tcp/ip stack and ensure your application talks to the others (probably legacy applications). In case you could go only with .NET it's better to choose .NET 3.5 and WCF framework instead of .net 2.0 remoting, the last one is dead and unsupported technology.