Request for next net_kernel release: new switch "net_setuptime_millis"

[Patrik Nyblom]

Hi again,

Here's a patch to make it possible to reduce the setuptime by using 
fractions of seconds (like 'erl -sname x -kernel net_setuptime 0.25').

Please observe, the result might be that, on a slow network, perfectly 
reachable nodes give connection failures if this parameter is set to low.

It all depends on your network, so use with care :-)

-------------------------------------------------
*** net_kernel.erl.orig Mon Jan 12 09:56:49 2004
--- net_kernel.erl      Mon Jan 12 11:02:47 2004
***************
*** 1336,1343 ****
 
  connecttime() ->
      case application:get_env(kernel, net_setuptime) of
!       {ok, Time} when integer(Time), Time > 0, Time < 120 ->
            Time * 1000;
        _ ->
            ?SETUPTIME
      end.
--- 1336,1345 ----
 
  connecttime() ->
      case application:get_env(kernel, net_setuptime) of
!       {ok, Time} when is_integer(Time), Time > 0, Time < 120 ->
            Time * 1000;
+       {ok, Time} when is_float(Time), Time > 0, Time < 120 ->
+           round(Time * 1000);
        _ ->
            ?SETUPTIME
      end.
-----------------------------------------------------------------------
The code is commited for R9C-1.

Cheers,
/Patrik

Reto Kramer wrote:

> I found where the 7s ping/net_connect delay I was seeing if I was 
> pinging (or multi_call'ing) a node who's connection had timeout comes 
> from (see net_kernel excerpt below).
>
> I'm glad it's configurable (thanks for the foresight, whoever did 
> it!), however I need it smaller than 1s, which is the current minimum 
> I can set.
>
> Is there any chance that in the next release of the net_kernel we 
> could add a new (equally undocumented, i.e. unsupported) switch: 
> net_setuptime_millis? I suggest the net_setuptime switch dominates if 
> present to maintain backwards compatibly.
>
> Funny enough, when the node in question (say c) never started in the 
> first place, then a multi_call to [a,b,c] does not suffer from the 
> connection setup delay, it's only because a connection (that timed 
> out) had been setup initially that I see the kernel setuptime 
> timeout/delay.
>
> Perhaps someone could educate me here - it seems that perhaps not all 
> the data structures associated with the timed out connection are 
> cleaned up (i.e. behavior is different from when the connection has 
> never been created in the first place).
>
> Thanks,
> - Reto
>
> PS: in the meantime, I'll resort to removing the failed node from the 
> nodeset I multicall to, and then re-add it using a multicast based 
> discovery protocol (the latter I have anyway). It would be nice if my 
> app could be naive about all that and just blindly multi_call to a 
> node set.
>
> --------- net_kernel: ---------
> [...]
> %% Default connection setup timeout in milliseconds.
> %% This timeout is set for every distributed action during
> %% the connection setup.
> -define(SETUPTIME, 7000).
> [...]
> connecttime() ->
> case application:get_env(kernel, net_setuptime) of
> {ok, Time} when integer(Time), Time > 0, Time < 120 ->
> Time * 1000;
> _ ->
> ?SETUPTIME
> end.
> [...]
> --------- net_kernel: ---------
>
> ______________________
> An engineer can do for a dime what any fool can do for a dollar.
> -- unknown