I'm building an application (both client and sever sides) that may need to send and receive data over the network. The messages will be short, and probably mostly binary. I need the connection to be secure even on public networks.
I'm not looking to reinvent the wheel, so I'd love if the protocol would handle all session-management overhead itself (handshake, dealing with dropped packets, sending back ACK responses, etc.). It will also be nice if it'd be naturally supported in Windows, Linux and OS X (by the .net framework, and the *NIX kernels).
So far, I've considered several options:
HTTPS - has good support for all of the above, except for the overhead. If the message is short, all the HTTP headers are just redundant. Natively supported.
IPSEC - is supported natively, but forcing me to handle the session myself.
Google's Protocol Buffers over HTTPS - the best option for now, but requires some implementation effort.
I'm new to the world of network programming, so any advice or tip would be greatly appreciated.
I think you'll first have to decide at what level you want to work. IPSEC as a protocol works at about the same level as IP; basically, you'll have to do everything yourself. HTTPS is a significantly higher-level protocol.
HTTP/HTTPS is universally supported, (with a little bit of work) will work through proxies etc. HTTPS gives you privacy and optionally authentication of the endpoints, at little extra cost. The operating system might even already provide a key store which you can use.
You can also open a socket and simply push encrypted data back and forth; think telnet or SSH (although SSH is fairly heavyweight during the protocol negotiation phase). Encryption libraries are available in or for most frameworks, but you have to be careful with key management and exchange. If you can live with using pre-shared keys, though, this is not necessarily a problem at all, really; otherwise, X509 certificates might be a workable approach that is readily supported on many platforms.
IPSec works on IP level, and it's used to secure network connections on system level. It's not usable on application level. So SSL/TLS is the best option as being the most popular and natively supported etc. If you want to use UDP, there exists DTLS protocol (TLS over UDP), but it's not as widely supported as regular TLS.
If you don't want to deal with sockets at all and prefer to focus on business logic, take a look at our MsgConnect product. This is a lightweight cross-platform message-oriented middleware, which lets you send and receive messages and MsgConnect will deal with sockets itself.
Related
My question is in regards to the number of persistent connections. (Obviously there will be performance loss when adding SSL Encryption).
Currently I have C# server and client applications that use the Asynchronous Socket model http://msdn.microsoft.com/en-us/library/w89fhyex.aspx. I choose this model because it seems best suited to performance and the server application must support 5000 persistent socket connections.
I am at the point where I must secure the data being sent, and I am hoping to use SSL. Would I be able to change to SSLStreams and still support 5000 persistent connections? (I noticed that SSLStreams have asynchronous methods... Also, the reading I have done indicates that a stream is different but the same as a socket...)
One caveat is that the Server does not only communicate with other C# devices, it also talks to iOS, and Android.
Is there anyway to layer SSL on top of the Asynchronous Socket model?
If you can use third-party components, then SSL components of our SecureBlackbox product fit your task perfectly: they provide SSL layer which can be plugged to absolutely any transport, be it synchronous or asynchronous socket or even pigeon mail. And overall feature list is much wider than of built-in SSL.
I'm looking for a c# tpc server, or a tcp server that has c# interface, that supports authentication from client to server, maybe via username/passwords or certificates, supports ssl/tls for transport and generally supports incoming channel to forward messages to server and outgoing command channel to send commands to event forwarder, like change this, and perhaps works on Mono as well as Windows, and is performant, i.e. can support multiple (dozens to hundreds of clients), as well as Windows IOCP.
I did look at WCF, but it's too vast/heavy for my requirements.
Thanks.
regards
Bob.
IIS seems like the obvious choice.
Found the following which can be called from c#. Its a high performance Windows IOCP based TCP Server.
http://code.google.com/p/potatofoundation/
I'm looking for the simplest way to connect a WWSAPI client to a WCF server that satisfies a couple of requirements:
No certificate management required.
Is secure.
WWSAPI obviously doesn't support message level security so standard WSHttpBinding is out, so I was hoping for people more conversant with the technology would be able to offer a suggestion to the most appropriate binding/security combination(s).
Thanks!
Given the lack of answers I'll summarize my own findings after researching this over the past week:
WWSAPI's lack of support for message level security rules out using HTTP with message level security.
My self-imposed restriction on certificate management rules out HTTPS.
That leaves TCP as the only secureable system supported by WWSAPI, and the easiest approach for that is transport level security (again, the only level supported by WWSAPI) with Windows authentication.
Obviously this has other limitations around firewall usage (TCP communications generally need to have ports specifically opened for them) and domain/AD usage (Windows authentication appears to require a trust level between the two Windows accounts in use), but it would definitely be the simplest way.
And for those looking for the best way, my conclusion would be to use HTTPS and work your way through handling certificates appropriately.
I have a .Net service hosted on a server, and .Net clients connecting to this server over the internet.
I want to implement a publish subscribe model where clients can subscribe to events on the service and have data pushed to them as data becomes available. An alternative would be to have clients poll the server for data, however this will likely be too slow for what is required. Hence the need for a publish/subscribe type of communication.
I understand that the WCF binding WSDualHttpBinding does allow this, however it comes with a downside. According to "Programming WCF Services" author Juval Lowy,
...the WSDualHttpBinding is mostly
unusable, since it is practically
impossible to tunnel through various
communication barriers separating the
service from the client and the need
to find a specific web-server machine
makes this impractical.
I've interpretted this to mean (please correct me if I'm wrong) that to operate with WSDualHttpBinding, it is necessary for clients to open a port on their machines (along with any necessary router configuration) for the server to callback through. If this is the case using WSDualHttpBinding will not be an option for me. Using Windows Azure will also not be an option.
So the crux of my question is, how can I achieve a publish/subscribe/callback type of communication over the internet, without the need to open ports on the client machine? Open standards are ok but unnecessary as client and server are both .Net, Windows Azure is not an option.
WSDualHttpBinding contains two channels one from client to server and second from server to client. The later one indeed requires firewall and NAT configuration. What about Net.Tcp? It uses only single channel and supports callbacks (duplex communication) over that channel initiated from client to server. You mentioned that both client and server will be .NET application so it should be possible with some firewall configuration on the server.
You mention most of the options in your post.
There are 3 options:
Client polls the server. Does not require open ports but too slow.
WSDualHttpBinding requires opening of ports
Azure Service Bus, would do it but not an option.
There is actually a way to do it. If you look at how Azure service bus works, it tricks the client into thinking that it is on an out going port, when really it being used to send messages to the client. You could try to implement this functionality.
Another thing you could try is nservicebus at http://nservicebus.com/, this is an open source .net service bus.
Internet Communication Engine (ICE) offers IceStorm, a publish/subscribe service.
Its open source, and if you download the installation there is a sample Visual Studio project that demonstrates how to implement publish/subscribe (check out the "demos" .zip file and the "IceStorm" directory with the clock demo).
ICE will do all the heavy lifting for you, the learning curve is remarkably short, primarily because the documentation is massive, approachable and well written.
I strongly recommend you DDS (data distribution service from OMG) over the internet http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%203/03-02_Bertocci_et_al.pdf
From OMG, that's all I gotta say. Yes, I know you may think OMG is over. I don't, and as a government counselor I really push for standards. Keep in mind that besides the liberal ideology and crises, governments are still a huge customers and inter-operation is a must.
NServiceBus? Right, ok, that's fine, but ain't too complex to start right now? Learning curve is too ... steep? I guess is not but, any easier one?
ICE is a good choice. guys from CORBA world trying to make things better. Don't doubt it, use it, try it! Just a feeling: even with the storm service you might feel you are still in the request/reply world ... but is that a con?
But if you rather prefer a commercial but open solution, think about publish subscribe using protocol buffers (search Google protocol buffers) ... just a first approach http://protocolbus.casessite.org . This is my owm work ... sorry it's just an initial project but I'm working with a central broker distribution as an alternative transport (default is multicast but broadcast and udp is also available). Open source, so be free ...
I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?
Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.
If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.
Remoting
If all development is done in .NET 2005, Remoting is the best way to go.
MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.
The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.