1

A lot of the good posts on .Net sockets seen on SO are around writing scalable high performance servers.

High performance TCP server in C#

How to write a scalable Tcp/Ip based server

While those posts are very good, what are the core things to focus on when writing high performance TCP Client Applications?

A scenario for a high performance client would be an application that streams requests to a server and processes responses in a non-blocking fashion.

Such a client should also have a strategy for reliable disconnect detection.

To further clarify, we have no control over the server end.

We simply have a server endpoint to connect to.

zmqNet mentioned in the comments is a great lib, but I think its strongest (or meant for cases) where both ends of the connection are using zmq (true?).

Community
  • 1
  • 1
Charles Okwuagwu
  • 10,538
  • 16
  • 87
  • 157
  • 1
    Have you looked at ZeroMQ? http://zeromq.org/ It does what you want plus loads more and has implementations for many languages. – Nebula Sep 28 '15 at 07:21
  • I second @Nebula 's suggestion. You have managed implementation of [zmq now](https://github.com/zeromq/netmq) – Sriram Sakthivel Sep 28 '15 at 07:26
  • @Nebula I had played with it long ago. I was hoping to find something backed into the .net framework, not an external library as such. Thanks though. – Charles Okwuagwu Sep 28 '15 at 07:28
  • @CharlesO I'd really recommend netMQ too, it has come a long way the last years. It stable, fast and easy to use (well the normal setup anyway). There's nothing in the framework that is comparable AFAIK. – Nebula Sep 28 '15 at 07:47

1 Answers1

1

Go with netMQ (0MQ). It's available as a NuGet package so that should be easy to maintain.

I'd suggest something like a client-side request socket and a router/dealer construction on the server side. The documention providere here: http://zguide.zeromq.org/page:all is excellent.

Nebula
  • 1,045
  • 2
  • 11
  • 24
  • Noted. What would you recommend for cases where i have no control over the server. For example the scenario i described in the question. – Charles Okwuagwu Sep 28 '15 at 08:02
  • Also, what is the story here as regards re-connection and dropped connection detection? – Charles Okwuagwu Sep 28 '15 at 08:12
  • Ah, the plot thickens, I assumed you had control over both since you referred to the high performance server thread. In that case I'm not sure 0MQ will fit your bill since it follows it's own protocol. Apart from rolling your own, I don't know any library that does fit your bill without knowing a bit more of the protocol you must use. With regards to reconnections 0MQ is phenomenal, connection order (server-client) is irrelevant and even yanking out the plug and pushing it back in is properly handled. – Nebula Sep 28 '15 at 08:21
  • Say you have a TCP server on the other end. you simply wish to have the benefits a high performance, disconnection aware client socket. How would you go about this? would you use ZMQNET in that instance? – Charles Okwuagwu Sep 28 '15 at 08:37
  • I have no experience with something like that because I have always had control over the server. Having said that you can probably force 0mq. But I can imagine because it allows you to create your own messages with certain sockets. Given the fact that other people have asked similar questions http://stackoverflow.com/questions/27182180/how-to-reconnect-to-a-socket-gracefully I doubt there is any generic approach to you problem. Ofter reconnects are closely tied to the protocol used. – Nebula Sep 28 '15 at 08:58
  • hi, i just read through that post the 240 second wait is not possible in my scenario... but heres the thing if i put a connect disconnect in a loop with a timer it fails to reconnect as expected. but if i restart my app the same connection works. I am guessing it is the client port that is not released within 240 seconds not the server port. – Charles Okwuagwu Sep 28 '15 at 09:08
  • 240 is just a default, you can set it way shorter: https://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.receivetimeout(v=vs.110).aspx – Nebula Sep 28 '15 at 09:23