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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
