On Dec 12, 2006, at 2:26 PM, Sam Lang wrote:
Primarily, I want to confirm that BMI_meth_method_addr_lookup()
prior to both the recv and the sendunexpected.
Yes, that's correct.
Thanks.
On the server, I wait for new connection messages, then I create a
new method_addr_p and register it using
bmi_method_addr_reg_callback() as well as my own connection
management structure. I then send my own ack to the client, which
allows it to start sending messages.
You're talking about the initial handshake that mx is going to do,
right? I think as long as you call the reg_callback, everything
else is up to you.
From outside the bmi interface, the first BMI call made (besides
the context init stuff), is to BMI_testunexpected. I'm not sure
that answers (or that I understand) your question on the server
side though.
-sam
Yes, it does. On the server side, I would expect the following:
BMI_meth_method_addr_lookup() /* lookup my "listen" address */
BMI_meth_initialize() /* startup and listen at the above
method_addr_p */
<some time passes>
BMI_MX detects a connect handshake request from a new client
BMI_MX creates some stuff for BMI_MX
BMI_MX acks the handshake request
BMI_MX allocs a new method_addr_p
bmi_method_addr_reg_callback() /* register the new method_addr_p */
BMI_meth_testunexpected() /* check for messages */
Thanks,
Scott
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
