3

I'm currently reading into WCF and also Sockets (here and on MSDN).

From what I saw WCF is slower than sockets but easier to use.

With the following Situation:

  • 500 Clients
  • Clients send requests to the Server which it responds to
  • Clients also send Status reports to the Server

  • Server Responses can range from Message received to transferring 200 MB data to them.

  • All communication is encrypted (example SSL)

The target of mine is that all communication is handled as safe as possible (safe in terms of Problems like exceptions, timeouts, ...), and that ist easy to maintain the program.

Also the less data Transfer intense requests/Responses Need to be fast (thus only a few KB of data transferred).

My question here is, with WCF being slower than sockets.....would WCF still be fast enough to handle such a large System / Situation, or would sockets be the better way there?

Edit: As mentioned in the comments ASP.NET and other web based Solutions could also do These, so not only normal sockets but also websockets are of interest there (web sockets vs. wcf should not be much different than sockets vs. wcf).

Thomas
  • 2,886
  • 3
  • 34
  • 78
  • By sockets you mean websockets? – Evk Nov 24 '17 at 10:22
  • 2
    SSL does not *encode* data, SSL *encrypts* data. There's a huge difference there. Sockets (if you mean the Socket class) are the lowest network type on .NET, so yes, that'd be always the fastest yet the slowest to program. WCF is barely used anymore, basically only for intra-network applications. For HTTP/HTTPs, look up on ASP.NET Web API or ASP.NET Core. That said, 500 clients is a pretty low number. – Camilo Terevinto Nov 24 '17 at 10:25
  • @CamiloTerevinto tnx I knew there was another word than Encoding but Google only brought up encode. Will correct it in the text asap. We used asp.net so far and had only Troubles (IIS hanging up, ....) which is why we are discussing to do it differently now (and sockets and wcf came up) – Thomas Nov 24 '17 at 10:37
  • @evk No I meant sockets – Thomas Nov 24 '17 at 10:38
  • With raw sockets you will just spend a lot of efforts for nothing useful. 500 clients is not much and anything can handle such amount, there is no need to seek for ultimate perfomance optimizations. Given your description - I'd just use asp.net (not a fan of WCF). – Evk Nov 24 '17 at 10:40
  • Writing a WCF service might take you 1-2 days. Writing a robust socket solution might take you 1-2 months, unless you have worked with lots of low-level TCP stuff. So rather write the WCF service & see if it's performance is good enough. If you decide it isn't, you can still use the majority of the core code. Just write the WCF stuff using configuration, not code, & you'll be done in no time. – Ashley Pillay Nov 24 '17 at 10:45
  • @evk May soun dumb, but asp.net can handle such cases (and also 500+ MB files) without Problems? (we had some Problems but could have been the architecture of the program that caused them back then) – Thomas Nov 24 '17 at 11:19
  • @Thomas yes it can. Asp.net is not worse than any other web server technology. That said - I'd suggest to use asp.net core and run that on linux server, behind nginx. I didn't run any asp.net applications on windows for years (before asp.net core I used mono). – Evk Nov 24 '17 at 11:53

1 Answers1

2

Websockets work on a lower level than WCF, so it will also be 'faster' in that sense.

But first I would question if you really need this extra speed?
It is a bit like asking if you should buy a Ferrari instead of a Mini, because the Ferrari is faster.

Yes, but unless you always need to race around at 200+ km/h then you will not get any benefit, especially on roads where there is a 50km/h speed limit!

You need to first determine what you are real needs. The number of clients (500), and the size of an occasional large response is not going to make much difference. You need to determine how many requests you need to process per second. The average size of these requests. And then based on this your required bandwidth.

Remember, that the physical cables (or wifi network) operates at exactly the same speed, no matter what technology you use. So actually 'speed' is not the issue, but bandwidth or latency might be.

These problems are solved by having the right architecture to handle your requests. This means being able to scale out your application to cope with your demands.

So, you need to determine what is the bottleneck in your application. For example: Your sever will have to do something with the data it receives, maybe write it to a database. This could be your bottleneck, so then Websockets or WCF makes no difference to how many operations you can process per second.

Similarly, if your sever is single threaded then it doesn't scale, so again the technology used makes not difference and it is not your problem.

Maybe you are focusing too much on one aspect, rather than the bigger picture. I think you might have a bit of an XY problem here!

I did also found these, which might be interesting; https://msdn.microsoft.com/en-us/library/bb310550.aspx

WCF performance, latency and scalability

http://www.ganshani.com/blog/2014/02/optimizing-performance-of-your-wcf-services/

http://theburningmonk.com/2010/05/wcf-improve-performance-with-greater-concurrency/

I'm sure you can find more

jason.kaisersmith
  • 8,712
  • 3
  • 29
  • 51
  • OP is talking about `sockets` not web sockets. Note the tag in the question. Otherwise good answer :) –  Nov 25 '17 at 04:09
  • @MickyD. Unfortunately that tag was posted after my answer, and I made a (false) assumption! – jason.kaisersmith Nov 25 '17 at 15:53
  • 1
    @jason.kaisersmith I think though that between websockets and sockets there is not enough difference that the answer inregards to "just" sockets would be much different. I'm going to adapt the question there a bit thus. – Thomas Nov 27 '17 at 10:33