Re: ENRP Peer Name Update

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 4. August 2004 09:43 schrieb Qiaobing Xie:
> Thomas,
>
> Thomas Dreibholz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear all,
> >
> > ENRP PEER_NAME_UPDATE contains the full Pool Element Parameter even in
> > case of deregistrations. ASAP DEREGISTRATION only uses a PE Identifier
> > Parameter to identify the PE. This is sufficient to identify and remove
> > the PE. So, what about defining to also use a PE Identifier parameter for
> > deregistrations in the PEER_NAME_UPDATE? That is, in case of
> > registrations PEER_NAME_UPDATE would contain a Pool Element Parameter and
> > in case of deregistrations a PE Identifier Parameter.
>
> The advantage of using a single format for PEER_NAME_UPDATE is to make the
> implementation easier and to keep the number of messages small (remember we
> also have PE update in addition to add and remove). In the case of removal
> (I wouldn't call it de-reg, see below), we may allow the sender to only
> fill in the PE-id and leave other fields blank and allow the receiver to
> ignore the other fields. But I do not see the value of using different
> formats.

When a NS applies a deregistration from the namespace, it first calls a 
function to delete the NS from the namespace. Then, the information about the 
PE is gone (memory is deallocated). This implies, that the PE information has 
to be duplicated (including malloc()/new calls -> error handling becomes 
necessary) before the deregistration to be able to fill out the 
PeerNameUpdate message. It is not recommended to send PeerNameUpdates before 
deregistering the element itself from the namespace, since a deregistration 
may fail (permissions, etc.). Using only a PE ID, it is simply necessary to 
remember a 32-bit integer value (fixed-size, no malloc()/new necessary).

When parsing a Pool Element Parameter having fields set blank and things like 
pool policy and user transport missing, all procedures requiring a complete 
Pool Element Parameter have to check if the parsed parameter is valid. If we 
do *not* allow to leave fields blank and skip user transport/policy 
parameter, a pool element parameter scanner procedure can directly verify if 
it is complete. No special cases are necessary. And finally, a Pool Element 
Parameter having all fields except the ID set blank, is nothing more than a 
degenerated Pool Element Identifier Parameter.

Conclusion: Using Pool Element Parameter for ADD_PE and Pool Element 
Identifier Parameter for DEL_PE decreases the complexity of the 
implementation and is IMHO useful.


Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email protected]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBLbCg32BbsHYPLWURAsGhAJ9fiMHPIJkhby16G6eETpTAD6oL/ACg2E1b
//mzvhxT1ha19O9AfYzpXXQ=
=u2dq
-----END PGP SIGNATURE-----