2

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.

Anthony
  • 441
  • 1
  • 5
  • 20

2 Answers2

2

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
Dmitry
  • 17,078
  • 2
  • 44
  • 70
  • The information sent over the wire should be small. A similar program to reference would be HoundDog (now owned by GFI and called GFI MAX). The clients are quite lightweight by nature, you set them up to monitor every so many minutes/seconds etc. and they send alerts as needed, they also send a ping letting the HQ server know it is still alive. So really very little data. The issue is more of a question as to how many clients there will be: There could be thousands per server. Do you think using WCF would be a better option? I'm just afraid that I will have to pull it all out after. – Anthony Aug 25 '11 at 23:08
  • As for time frame, this is my own project (among others) which I am working on while unemployed. So typically I have all the free time I need. I do want to learn socket programming but I would also like to see a working model within a month or two. I honestly don't mind using newer methods (or encapsulations) if they will work in the long run. – Anthony Aug 25 '11 at 23:11
  • To add also, I originally (way back in VB6) was a Windows Forms programmer... then I shifted to ASP.NET Web Forms and have been there for a number of years so this is the first venture back into Windows Forms programming for me. I know the differences and am well informed about networking. To put it simply, I'm going on what other people are saying in articles and help blogs etc. As such many people say WCF is "heavy" but then like you say the "complexity overhead introduced by using sockets" could also be a frown factor for me... Sheesh, it's never straightforward is it :) – Anthony Aug 25 '11 at 23:15
  • 1
    Go with the technology that will get you up and running fastest, plain WCF+HTTP might be a good choice. Do not optimize until you have a hard numbers that identify bottleneck. If serialization is the bottleneck try using 'leaner' format like proto buffers. – Dmitry Aug 25 '11 at 23:36
1

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:

Community
  • 1
  • 1
Adriano Carneiro
  • 57,693
  • 12
  • 90
  • 123
  • When you say "reinvent the wheel here" what exactly do you mean? If there is a better, faster more standard way I'm all ears. Yet I may learn a lot from starting at the bottom like you say. – Anthony Aug 25 '11 at 22:40
  • OK, so after looking at those, I assuming you are directing me to use JSON or XML to send my objects. Is this correct? Is this the way it should be done now? Keep in mind that most of the examples I have sen are from around 2008/2009 – Anthony Aug 25 '11 at 22:46