Hey Chuck,
My apologizes for the delayed response...
On 03/17/2010 10:39 AM, Chuck Lever wrote:
> On 03/17/2010 06:36 AM, Steve Dickson wrote:
>>> /*
>>> - * Successful NOTIFY call. Server returns void, so nothing
>>> - * we need to do here.
>>> + * Successful NOTIFY call. Server returns void.
>>> + *
>>> + * Try sending another SM_NOTIFY with an unqualified "my_name"
>>> + * argument. Reuse the port number. If "my_name" is already
>>> + * unqualified, we're done.
>>> */
>>> static void
>>> recv_notify_reply(struct nsm_host *host)
>>> {
>>> - xlog(D_GENERAL, "Host %s notified successfully", host->name);
>>> + char *dot = strchr(host->my_name, '.');
>>>
>>> - smn_forget_host(host);
>>> + if (dot != NULL) {
>>> + *dot = '\0';
>>> + host->send_next = time(NULL);
>>> + host->xid = 0;
>>> + if (host->timeout>= NSM_MAX_TIMEOUT / 4)
>>> + host->timeout = NSM_MAX_TIMEOUT / 4;
>>> + insert_host(host);
>> What happens when host->my_name now resolves to host in a
>> different domain? Will this mean we now will be sending SM_NOTIFYs
>> to random hosts?
>
>> Also, what happens when host->my_name does not resolve to anything?
>> Looking at notify(), it appears the unqualified my_name will stay
>> on the hosts list, because notify_host() will fail since the
>> smn_lookup() fails and will always set host->ai = NULL. Unless
>> I am missing something, this will cause notify() to increment
>> hp->retries and insert the hp pointer back on the host list.
>> I don't see how that cycle will broken....
>
> host->my_name isn't used to generate the recipient's address, host->name
> is.
>
> host->my_name is the _argument_ of an SM_NOTIFY request. That argument
> is used as a search key by the remote, but sm-notify does not use this
> string for DNS resolution.
Ok.. I see that now... thanks...
steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
