[Pvfs2-developers] Re: the halloween bug fixed

[Scott Atchley]

On Oct 8, 2007, at 2:50 PM, Sam Lang wrote:

>> I am not sure what you are proposing that  
>> bmi_method_addr_forget_callback() do.
>
> bmi_method_addr_reg_callback is called at mx.c:2290, in icon_ack,  
> where peer->mxp_exist is set to 1.  It doesn't look like that  
> variable is used (checked or set) anywhere else.

Correct. This is used on the server only and is used to prevent  
bmi_mx to register the same client twice.

> Does cleanup/shutdown of that peer ever occur?

Cleanup (freeing of data structures, etc.) only occurs at the  
direction of BMI via BMI_set_info(DROP_ADDR).

If the client stops communicating and the server has no outstanding  
requests posted, the client's status will forever remain  
BMX_PEER_READY (i.e. connected).

If the client stops communicating and the server has outstanding  
requests, those requests will time out and the peer status will be  
changed to BMX_PEER_DISCONNECT. The server will maintain the various  
data structures (128 bytes plus the lengths of the peername, the  
mx:// URI, and the hostname).

Is it this case that you want the BMI method to notify BMI with  
bmi_method_addr_forget_callback? Or in both cases?

Assuming the client is gone forever and assuming that it disappeared  
unexpectedly (the server had pending requests), then this will free  
the 128+ bytes in bmi_mx used for that client.

When a client intends to stop communicating with a server, does it  
send some kind of goodbye message to the server? If so, does the  
server call BMI_set_info(DROP_ADDR)?

> Also, is it possible for the same client node to appear as multiple  
> different peers to the server node?  It sounds like the answer is  
> no, but I just want to make sure.
>
> -sam

You are correct.

Scott