On Mar 5, 2008, at 10:59 AM, Phil Carns wrote:
I don't know if IB or MX need to use the
bmi_method_addr_forget_callback() function. That function makes a
little more sense in the context of a particular tcp problem:
- each time a client opens a new tcp socket to a server, the server
creates a bmi_addr corresponding to that socket (so it can send
responses, etc.).
- if that client exits, then reconnects, the server just thinks of
that as an entirely new bmi_addr; it doesn't have any way to
realize that it is the same client connecting again using a
different socket.
bmi_tcp therefore has to garbage collect old bmi_addr's when
sockets close, otherwise the number of addresses can grow
indefinitely for a long running tcp pvfs2-server (a problem Sam
found a while back).
Ideally, when bmi_tcp figures out that a socket is closed, it would
garbage collect immediately and get rid of the addr. However, the
server could still have pending operations for that bmi_addr.
So... we we mark that addr as in an error state and try to hang
onto it until the reference count hits zero before garbage
collecting. That let's us report a more meaningful error on the
server side for pending operations than "addr doesn't exist".
The bmi_method_addr_foget_callback() in this case is a way to poke
the upper level bmi code to say "keep an eye on this addr, and when
the refcount hits zero clean it up for me".
I don't know if that description helps any, but that's my
interpretation of what it does :) The address management (in
general) in bmi has ended up being pretty wacky.
The DROP_ADDR function is how the bmi.c layer explicitly tells a
bmi method to get rid of an address (if that action makes any sense
for the method in question). So that part needs to really get rid
of the address if necessary rather than handing it back to bmi.c
with the bmi_method_addr_forget_callback().
-Phil
Thanks Phil,
I will remove the callback from bmi_mx.
I think that I also need to look at sending a BYE message when a
client goes away to let the server know when to clean up.
Scott
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
