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
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 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.
I'm getting into socket programming on C#.net for the project I am writing.
The project will be a multi-client system of which the client services monitor system resources and report back to a central server(s).
I was looking into Remoting, WCF etc. to determine which would be best for me. I settled with socket programming because of a number of requirements:
Sockets are faster than the rest with little overhead
I can support more connections per resources on the servers
Sockets can, with albeit modifications, allow me to interact with UNIX based systems also.
I can implement encryption on the link myself in code without having to rely on an SSL cert.
I may be wrong in my thinking here? If I am please do tell. Some suggest WCF as it is "wasy to use" and does everything I want but I believe it is that much slower with overheads.
My main issue is, that while the client machine will not keep a connection open, there could be thousands, or tens of thousands, of client machines and I would have to assume that the machine will be hammered with connections. Considering minimum times between connections, per client, may be as small as 1 min.
Now to my problem at hand: How to send multiple objects over the link and more importantly how to determine what they are on the other side?
I'm assuming this is possible over one connection as I have read a number of articles saying so, albeit they describe the methods differently and so are the examples.
The issue is I can't find any example that actually does this. No example shows how to send multiple objects and then how to determine what they are on the other side.
Can anyone help me here or point me to examples. I'm quite able to figure stuff out once I have a base to work from.
It feels like the classic case of premature optimization and reinventing the wheel. I might be mistaken because I don't know what are your performance requirements, development resources and time frame. But I suspect that very smart people had the same problems before you. And they came up with the variety of solutions, including HTTP (SOAP, REST) and XMPP (if you want statefull protocol). A lot can be done to improve performance even at the app level (minimizing amount of data send over wire, caching etc). Without complexity overhead introduced by using sockets directly. You probably know all of this but I highly recommend you to evaluate your decision again.
As to usual serialization format suspects like XML and JSON you might also want to look at Protocol Buffers:
protocol buffers is the name of the binary serialization format used
by Google for much of their data communications. It is designed to be:
small in size - efficient data storage (far smaller than xml)
cheap to process - both at the client and server
platform independent - portable between different programming architectures
extensible - to add new data to old messages
You might be trying to reinvent the wheel here. But since you have set your mind about using sockets (been there, done that, learned a lot), read those links on serialization:
How to deal with XML in C#
XML Serialization and Inherited Types
How do I serialize a C# anonymous type to a JSON string?
Parse JSON in C#
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.
So I have ASP.NET running on the server in IIS7. I think I'm going to use MVC for some static pages and basic dynamic forms - but the majority of the client side is written in Flash/ActionScript.
What's the simplest, most succint, most DRY way of building/generating proxies between client and server?
Which format should I use?
JSON
SOAP
Binary
And which comms protocol should I use?
WCF
HTTP via MVC Controller actions
I'm probably missing some format or protocol, but basically it should be relatively efficient, not require alot of plumbing code and preferably auto-generates client-side proxies.
WSDL web services are very easy to consume in Flash and simple to create in .NET.
I'd also suggest you at least look into AMF, which is Adobe's proprietary binary format for exchanging data between client and server. There are a couple of implementations for .NET, including amf.net and weborb.
I've never used it, but I've heard really great things about weborb: http://www.themidnightcoders.com/products/weborb-for-net/overview.html
i've consumed JSON in swfs .. pretty simple using a3corelib stuff
I have had a good experience with FluorineFX.net - It appears to be very similar to WebORB but its free and open source. I don't think Flash/ActionScript supports WCF..
You should note that (in the research I've done) there is no way to send a packed from the server to the client - the client must make all requests.
We use Weborb at my work. I highly recommend it. There are some gotchas with the way Weborb handles serialization on both ends. Just make sure in your .NET classes you don't have member names the same as class names.
EDIT: The free developer edition of Weborb should meet most people's needs. Weborb has the distinct advantage of speed, because it uses the binary AMF format to talk over the wire instead of JSON or SOAP.
I second WebORB. It uses the AMF protocol which is that fastest way to get data in and out. You can easily expose your .NET services and have typed objects going in and out. You can use RMI and Messaging. It's a free product and does a great job...
WCF supports Flash..! Done with "AJAX-enabled WCF Service" and WebInvoke(Method = "POST")