Re: ENRP Server Hunt Timer

Hi,

A general comments to this timer discussion.

There are a lot of useful stuff and interesting details if we look at rserpool from an 
implementation's perspective, such as many things being talked about in this thread. But not 
necessarily all of them should be documented in the spec. IMO, only those details which, if 
ignored, would 1) cause interoperability problems, 2) impact the network in a negative way, 
or 3) undo a designed feature should be documented.

Moreover, the spec should always be written conservatively since it is a known fact that the 
implementations are always the ones that push the envelop of aggressiveness.

With the above in mind, I would NOT recommend to put text suggesting the use of a ceiling 
for the timer and continuous try at the ceiling. These are aggressive behaviors and very 
likely many implementors will try to do without the spec asking them to. There are 
aggressive since they may negatively impact the network if the ceiling is set too low or the 
endpoint just refuses to give up trying forever.

If we really feel that the ceiling and continuous try are essential to rserpool operation 
and must be supported (I haven't been convinced that they are), then we should have text in 
the spec to explain it (including how they are essential to rserpool). And it must say some 
thing like - if the ceiling is used, it MUST NOT be too small. Or if continuous try is used, 
it MUST come with a mechanism that the endpoint will give up at some point. IETF won't want 
some endpoints injecting infinite packets into the network.

regards,
-Qiaobing

Thomas Dreibholz wrote:

> On Tuesday 02 November 2004 14:16, c s chandrashekaran-A14667 wrote:
> 
>>I agree with the upper limit and with the idea of continuing to try (I
>>think at the upper limited value of the timer). However it may be simpler
>>to keep retrying forever. The application or user, can decide after certain
>>number of failures to use ASAP (like register; name resoution etc) whether
>>or not to shutdown. We would not need an additional configuration parameter
>>in that case.
> 
> 
> This would imply an asynchronous API, e.g. the user calls 
> StartNameResolution(), which initiates the name resolution in background and 
> returns immediately. Finally, the user application is notified - by signal (a 
> bad idea!) or callback - and then calls a function GetNameResolutionResult() 
> - or the user aborts the name resolution when he decides to have waited long 
> enough. Example:
> 
> void callback()
> {
>    Notify main program that name resolution has been successful
> }
> 
> ok = StartNameResolution();
> if(!ok) {
>    cerr << "ERROR: Unable to initiate name resolution" << endl;
>    exit(1);
> }
> Start a timer -> nameResolutionCallback
> ...
> while(...) {
>    if(Name Resolution Event) {
>       Name resolution successful!
>    }
>    if(Timer Event) {
>       Name resolution failed!
>    }
>    ...
> }
> 
> Probably, the program also has to care for thread safety in the callback 
> function!
> 
> 
> An asynchronous API is quite complicated. Giving a maximum number of trials 
> directly to a NameResolution() function is much easier to use and much nearer 
> to the existing DNS name resolution API. Example:
> 
> result = NameResolution("MyPoolHandle", 10 Trials)
> if(result == NULL) {
>    cerr << "ERROR: Name resolution failed!" << endl;
>    exit(1);
> }
> 
> 
> Best regards