Re: ASAP Handle Resolution Option

I don't see much usefulness of this new option.

When you want the server to select a few out of all PEs, are you 
thinking of making the server to use some selection criterion? If the 
selection criterion is anything beyond random selection, you are 
actually adding considerable complexity and computational burden to the 
server side. If random selection is what you have in mind, them why not 
do it on the PU side after it receives the all the PEs from the server? 
Implementing on the PU side should be cheaper, transparent, and no need 
for standards.

regards,
-Qiaobing

Dirk Hoffstadt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Dreibholz schrieb:
>   
>> On Donnerstag 20 November 2008, Randy Stewart wrote:
>>     
>>> In this case you can configure it on the PU... its not that big of deal.
>>> Besides if you only want one response, why are you even bothering
>>> to use RSERPOOL. Its just as easy to use either a configured
>>> host or DNS to lookup the single guy you wish to talk to.
>>>       
>> Dear Randy,
>>
>> the idea is to configure the number on the PU. But the PU has to tell the ENRP 
>> server how many PE entries it actually needs.
>>
>>
>>     
>>>>>  - configuring the requesting PU side to discard all but the number
>>>>>    that he wants.
>>>>>           
>>>> Then, the ENRP has to unnecessarily select entries, which wastes a
>>>> lot of
>>>> processing power and network bandwidth. In summary, it is very
>>>> inefficient.
>>>>         
>>> This is rather silly in my mind. B/W on a network where rserpool
>>> is running is not going to be that much of a problem IMO. Processing
>>> power is a moot point with multi-gig-hz machines and Gig's of memory
>>> being the common environment. If you are not in that environment
>>> your NOT going to have 100's of PE's so I see NO need for this.
>>>       
>> Bandwidth it not really the problem. The actual problem is the unnecessary 
>> processing power it needs to select e.g. 100 PEs when e.g. actually only 1 
>> entry is really required. Why should the ENRP server need significantly more 
>> CPU resources than necessary when it is so easy to fix this problem? The 
>> handle resolution option is really simple (just 8 bytes containing a single 
>> entry) and successfully fixes this problem. With a few lines of 
>> implementation code, a significant performance gain can be achieved.
>>     
>
> Yes, I fully agree to that. The solution to solve the "number of PE
> entries to be selected" problem by the handle resolution option is
> really simple. Wasting resources should really be avoided, since this
> reduces deployment costs.
>
>
> - --
> Best regards,
> Dirk Hoffstadt
> - ------------------------------------------------------------------
> M.Sc. Dirk Hoffstadt
> DH Datentechnik
> 45219 Essen Germany
> E-Mail: [email protected]
> Internet: http://www.dhdt.de PGP-PublicKey:
> https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
> - ------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iQEcBAEBAgAGBQJJJW4/AAoJEAl0PP0XKTexStEIANm2uhUn0JHwHNg9xIBelyHV
> niqhi0zBOsiy36JtoanDLMgFLNd/uzGDBdViX/OLMJFSCuHmEXD3pjA6/avCzY0r
> qL6rHb5pr2yfq6ALqzpQ9yODUFdWH55XSWDQH3aIRhoD74n0L5NvuHHz7g9BNjv5
> uWAiRAL1ljyWfsX6kbaE2iSpwVfg4RUPDCCcgsUcKoPxKR1Y9XFylc97ORWjYz7J
> hH2DkYApT5qIURnp7SU7FIeXRBb0ftXnZlqOdt6oQm4c9dTuojNeZr2XTpEnbQjz
> nMGBk7LmS/4beb2PdQPMl//VjCKh9FrzS4sZWYq0jEc9yCGuJQhg+R+/Qc3EM7g=
> =f1/2
> -----END PGP SIGNATURE-----
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rserpool
>
>