[cifs-protocol] MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334

Stefan Metzmacher metze at samba.org
Thu Jan 4 16:23:10 UTC 2024


Hi Jeff,

> I didn't see a response to my previous request. It's not clear to us what you are looking for here. Having a single netname for multiple nodes sounds similar to a SOFS configuration. We use DNS to enumerate the IP addresses.
> 
> Windows uses witness for the following:
> -	If networking interface on the server has changed then hint client about that so it can query list of new interfaces sooner than default 10 minutes poling interval.

Do you mean the witness GetInterfaceList() call or the FSCTL_QUERY_NETWORK_INTERFACE_INFO used for smb3 multichannel?

> -	If cluster node is down then notify client about that so it can disconnect from the downer and connect to some other node, before TCP/IP timeout expires. Would work only of cluster can detect downer faster than TCP/IP timeout.

I'll refer to this below with RESOURCE_CHANGE.

> -	If cluster has asymmetric storage (one node can process IOs faster than the others) then hint client that it should move to that node. In Windows if Direct IO is possible then storage connectivity is considered symmetrical and we prefer load balancing clients across all cluster nodes. If we are in File System Redirected IO (same blog) then storage connectivity is asymmetrical and client is advised to move to the node that has file system mounted to avoid double hop..

I'll refer to this below with CLIENT_MOVE_NOTIFICATION.

> All notifications are advisory.
> 
> Could you clarify your expectations for the doc and tell us more about what you're trying to accomplish?

I'll try...

> This is in regards to your question:
> Question 9:
> Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events. 

> E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName

So far I found this in my testing:

A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_UNAVAILABLE will trigger a reconnect,
but the RESOURCE_CHANGE.name content is completely ignored, currently I'm sending the ip address string
that's no longer available, it's mainly in order to make it easier to read wireshark traces or logs.
It could also be "SoME RandOM-StriNg!!!".

A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_AVAILABLE also doesn't have any notable effect.

I think this should be documented somewhere.

If needed I an create network captures for it.

> Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single InterfaceGroupName for all nodes?

The line/question above is no longer useful, as I found how to get the client react
on RESOURCE_CHANGE with WITNESS_RESOURCE_STATE_UNAVAILABLE.

But by testing I found that a CLIENT_MOVE_NOTIFICATION is ignored if the list of ip addresses
if the also contains the ip address that was given to the Register[Ex]() call.

I have only tested the case where all ip addresses have IPADDR_ONLINE set,
but I haven't tested if it's needed or what happens with IPADDR_OFFLINE or
when the given ip address if not part of the set that is resolved by dns
and/or isn't available.

I think this should be documented somewhere.

If needed I an create network captures for it.

> I'm ready to file document change requests to explain the processing, but I don't fully understand your example question.

I hope the above makes it clearer.

> Resource Change notifications are used when resources such as disks change status

The point is that as noted above it seems RESOURCE_CHANGE.name seems to be completely ignored.

> while Client Move notifications are used when a node has gone down and the client needs to move to another node.

Yes, I found what I needed, but these details should be documented somewhere
in order to let server implementers know how to drive a windows client to
a desired/expected behavior.

> They aren't interchangeable. Could you clarify your question?

I got it thanks!
metze




More information about the cifs-protocol mailing list