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.
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#
Greeting,
This month I will start working on my master thesis. My thesis's subject is about network security.
I need to deal with network interfaces and packets.
I've used shappcap before to interact with packets but I'm not sure if C# is the most powerful language to deal with network programing and packets.
I worked a bit with wireshark and I saw how powerful it is and as you know winsharp is open source developed using C++.
I'm not sure if I should use C# or C++ for network security programming and I want your through about the best language might be for network programming and packets interaction.
should I use C#, C++, or java or some thing else?
please give me your advice.
Thank you,
UPDATE
..........................
I'm going to do different packet mining by taking each packet and read each field on it then use these values and in same stages I would modify some of the packets value then resend them back.
I want to control the packet since it received by the network interface until it passes to the application layer.
also
You'd be able to do network programming using almost any language you want to. If you are equally comfortable in all of the languages you've mentioned, you should determine what system libraries or APIs will you be interfacing with. For example, if you will be doing packet-level network programming on a Unix system, C would probably be your best best. If you want to integrate with Wireshark, go with C++. If you want to use an Apache Commons component, use Java. I suggest you come up with a more specific set of requirements for your actual program before trying to decide which language to use.
WireShark uses WinPCap so you could go that route as well.
For security application, is that a intrution detection system or do you actually want to drop offending packets? WinPCap, SharpPCap etc. do not allow you you drop packets, for this you will need to look at some kind of intermediate driver or look at Windows Filtering Platform (WFP)
http://www.microsoft.com/whdc/device/network/WFP.mspx
IMHO, if you can find a callback driver that calls back to user mode and allows you to filter the packets from C# or C++, this would probably be fine for experimental purposes etc. but for a production solution, I think you would need to stick to the kernel level to ensure that you can keep-up with the peek volume.
Use C++, Boost and Poco and you can do what you want. Boost asio is: Portable networking, including sockets, timers, hostname resolution and socket iostreams. Poco library also provides solutions for network, cryprography NetSSL ... and more. For more information you can visit www.boost.org and www.pocoproject.org
You can use java if you like - jpcap works well.
I would suggest using C#, since there is a very strong library called Pcap.Net that wraps WinPcap with .NET code. This should make it easy for you to receive, send and interpret packets different packets of different protocols.
the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).