KeepAlive For Udp

Jul 6, 2011 at 3:03 AM

I notice that there are two ServerConfig properties named "KeepAliveInterval" and "KeepAliveTime" used by tcpSocket. SuperSocket use Tcp/Ip‘s keepalive to make sure the server can know every client is online or not.

I know Tcp/Ip implement this by do something like send heartbeat pack every keepalivetime senconds.So why not add this to the UdpServer .You can do it by your own way just like Tcp/Ip does.

Jul 6, 2011 at 4:44 AM

The KeepAliveTime/KeepAliveInterval is for TCP level keep alive, which is provided by .NET TCP implementation and only defined in TCP protocol.

The UDP protocol is connectionless, so keep alive of transportation protocol level is not reasonable, but you can do application level keep alive, which has been supported by SuperSocket.

Please take a look at the options below:

clearIdleSession: true or false, whether clear idle sessions. Default value is false.
clearIdleSessionInterval: the clearing timeout idle session interval. Default value is 120, in seconds.
idleSessionTimeOut: The session timeout period. Default value is 300, in seconds.
http://supersocket.codeplex.com/wikipage?title=Basic%20configuration&referringTitle=Documentation

Jul 6, 2011 at 5:30 AM

OK,I got it,Thank you for your help!

Oct 14, 2011 at 8:39 AM

Good morning ...

Reading about keepalive packets I would like to make you three questions to clarify some doubts that I have ...

1.- We are expecting thousands (3000- or more) of simultaneous connections (permanents till client close) in our server and I would like to know how much overhead can add enabling keepalive packets?

2.- The best way to detect dropped connections (by crash, cable off, ..) is using keepalive, Am I Right or not?

3.- Would keepalive packets interfere with my own implementation to validate connections with client/server sockets? Should I need to do something additional or the O.S. take care of that?

Thanks in advance

E/R.

Oct 14, 2011 at 8:47 AM

1. As my no-professional test, SuperSocket can handle 10k ECHO requests per second by EchoServer. TCP keep alive may be very light which nearly can be ignored. It is another story if you use your own keep alive.

2. Yes, Keep alive. You can use TCP's keep alive directly, but if it cannot satisfy your requirement, you can define your own keep alive.

3. If you want to implement your own keep alive, you'd better make sure the keep alive is client driven.

Oct 15, 2011 at 1:10 AM

Thanks for your quick answers ...

Just two more comments ...

1.- No, I'm not going to implement my own keepalive just the same included by default ... what I don't know if is that packet will interfere with my implementation to keep connections (validations, identifications, ...), I mean when the keepalive are enable is necessary to do something special to discard those packets? or are they specific to O.S. and exist no interfering at all?

2.- Our intention is to keep the connection alive for all the possible time the client require (at least, of course something happen), that can be extended or applied to a great number of simulataneous connections, as I said, maybe more than 3.000 or 4.000 at the same time alive.

3.- Using keep alive, We would like to detect dropped connections the most fast possible, maybe in at least 3 seconds or less, giving the chance to the client to reconnect in a established and configured limited period of time.

Any suggestions?

thanks in advance

regards,

E/R

Oct 15, 2011 at 2:10 AM

1. No, you needn't care keep alive when you do business communications, but I cannot image the case the keep alive is too frequently.

2. SuperSocket can handler more than 10K clients, so you needn't worry about the concurrent connection number.

3. There are two options to control TCP keep alive in SuperSocket, please set them in a proper value:

keepAliveTime: The interval of keeping alive. Default value is 600, in seconds.
keepAliveInterval: The interval of retry after keep alive fail. Default value is 60, in seconds.

 

Oct 15, 2011 at 4:09 AM

Wow 10k clients is more than enough per server ... for what I expect ... so, my next questions are ...;

1.- 10k clients with a buffer size for send and for receive more or less of what size?

2.- Can they (10k) interchange information simultaneously with the server with not apparently delay (just ms)?

3.- What (based on your tests and experience) should be the minimum hardware requirement to achieve it with no excesive degradation performance? I mean, maybe a computer with 2.4Ghz dual core, 4GB Ram, Windows 7 Enterprise or something suggested ...

I want to add one more thing ... thanks for your contribution and specially for taking the time to answer and be nice on interchange your thoughts ...

Regards,

E/R.

Oct 15, 2011 at 11:37 PM
Edited Oct 15, 2011 at 11:41 PM

Well after deeping and reading some articles and oppinions for people with experience in this area, I have concluded the following ...

1.- The meaning of keepalives is not exactly what I was thinking about at beginning, reading from MSDN even tweaking "Keepalivetime" to 30 seconds and "keepaliveinterval" to 1 second I have to wait for each retransmission before a not existed connection is really thrown, each retransmission is by default 5 (I think), further, the keepinterval is duplicated automatically in each retry to later be resetted to its initial value. Exits a considerable delay before the connection is really detected as dropped on unplug cable for example.

2.- Reading from Nito site and others web pages, We should take note that some routers or firewalls can discard packet of zero bytes, like the suggested from the example of MSDN in the connect property. Even can discard the zero size packet sent by keepalive bringing as consecuence the bad assumption of down connections when they're really exist and active, by error you can discard good connections.

3.- Apparently if it's really necessary detect dropped connections almost inmediately or faster, We should:

3.a.) Create a time property in the class containing the socket business connection (in the server) and reset each time an info is send or receive successfully, having a thread that check periodically for time of innactivity.

3.b) Create a delegate timer in the class containing the socket business connection (in the server) and check each elapsed time per connection more accurate but is more resource consumed than the previous.

3.c) Send periodically a heartbeat (configured on client and server) to detect connection that has been dropped and discard them, in this case is necessary to take care of that the defined heartbeat do not disturb our business logic communication.

According to some people Keepalive bring more problems that solutions to them. That's the case for example of router (depending on model or any other thing) acceptance or not of zero length packets.

It's important to notice that sometimes when We discard a connection maybe We are discarding a connection that can gracefully reconnected, for example unplugging and plugging again the cable after five minutes or some time will keep the connection still alive, or even a failure in the router and its returned activity will keep our connection working fine.

That's what I have understand, what all of you think about it? ... something wrong? more or better suggestions?

Cheers,

E/R

Oct 16, 2011 at 2:31 PM

SuperSocket supports 3.a) and 3.b),

The configuration items below control this feature:

clearIdleSession: true or false, whether clear idle sessions. Default value is false.
clearIdleSessionInterval: the clearing timeout idle session interval. Default value is 120, in seconds.
idleSessionTimeOut: The session timeout period. Default value is 300, in seconds.

Oct 16, 2011 at 10:29 PM

Pretty good ... I'll give a check and still revising you're great lib ... has many details to see ... I'll check the samples maybe you've implemented those properties ...

once again ... thanks ...

E/R

Oct 16, 2011 at 10:31 PM

I  forgot to mention that sometimes our clients could be in Idle state, so maybe our better approach is to implement a heartbeat from time to time ...

thanks.