Request for next net_kernel release: new switch "net_setuptime_millis"

[Reto Kramer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2066 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20040108/ae0933f2/attachment.bin>