I'm working on a simple network project, and would like to transfer objects directly using a TCPListener / Client connection. I would like to avoid the WCF overhead, and just have a simple way of serializing the object on the way out, sending it over the network, and finally restoring it back to the original on the other end.
Thanks
Remoting is out of favor now that there is WCF. WCF is highly optimized for performance and will win over remoting in most cases. See http://msdn.microsoft.com/en-us/library/bb310550.aspx. You don't mention whether you are worried about runtime overhead or the overhead of learning how to use WCF. That being said, you can reduce the runtime overhead by using the binary TCP transport instead of the HTTP one. It works well, though HTTP (SOAP) is, of course, highly popular now. Your service can support multiple transports (i.e., TCP and HTTP) to work well with .NET clients (TCP transport) and other standards-compliant clients (HTTP SOAP transport).
Look into .NET Remoting; it makes things easy!
And it's a big topic to display a sample in a comment here =)
Read here: http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx
Well if you need ONLY serialization/deserialization behavior without involving WCF or Remoting, there is a plenty ways:
Standard serialization via SerializableAttribute and BinaryFormatter
XML Serialization
Json.NET
Google's Protocol Buffers via ProtoBuf.NET
All approaches have strong and weak sides, but I believe that for your needs #1 will be enough. Reasonable compact and without external libraries need.
Related
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 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#
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.
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")