[erlang-questions] The odd behaviour of net_ticktime

[Tim Watson]

Just to clarify...

On 3 Jul 2013, at 10:28, Tim Watson wrote:

> Secondly, if I'm right, then why is net_kernel doing things this way? If there is traffic on a dist port (i.e., socket), then clearly we've not actually experienced a netsplit, and reporting one seems like the wrong thing to do.
> 

I did notice that the timeout checks the socket for activity - this is (presumably) handling the "TickTime * 4" i.e., 60 seconds inactivity timeout that's mentioned in the documentation?

> What I'm contemplating at the moment, is setting the net_ticktime to a very high value and implementing user-level heartbeats, combined with out of band checks (using getstat) on the dist ports in use, to verify that traffic is (or isn't) actually flowing before firing a 'DOWN' event. I really want to put all the effort in if this isn't necessary though.
> 

I'm still contemplating doing this, since such a long potential delay (viz 30 - 60 seconds) isn't tolerable. And besides, pushing net_kernel's tick timer out of the way isn't really plausible if the following comments from dist_util.erl hold true:

<quote>
%% And then every 60 seconds we also check the connection and 
%% close it if we havn't received anything on it for the 
%% last 60 secs. If ticked == tick we havn't received anything 
%% on the connection the last 60 secs. 
</quote>

That's frankly just confusing. It *sounds* like we cannot realistically extend net_ticktime to anything larger than 60 seconds, but in practise that "60 seconds" actually just means "TickTime seconds" right?

I'm trying to work out the utility of having a very low ticktime (such as 2 seconds) versus implementing user-level heartbeats. The former scares me, since it's such a fundamental element of system configuration, but the latter is a bunch of work I'd rather not do. I can tolerate a 10 second delay, but not a 60 second one.

Cheers,
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130703/1418715b/attachment.bin>