[Pvfs2-developers] Re: the halloween bug fixed

[Sam Lang]

On Oct 9, 2007, at 7:42 AM, Scott Atchley wrote:

> 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?

It sounds like it only needs to call the forget_callback in finalize  
for all the peers it knows about.

>
> 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)?

In the case of tcp, the socket is closed.  The server doesn't call  
BMI_set_info because notification of the disconnect is within the  
method.  This is why the callback is necessary.

-sam

>
>> 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
>