[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [EXTERNAL] Re: MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered w
From:       "Jeff McCashland \(He/him\) via cifs-protocol" <cifs-protocol () lists ! samba ! org>
Date:       2024-01-08 17:58:30
Message-ID: MN0PR21MB37019E7AEFB35E5B5462FB2BA36B2 () MN0PR21MB3701 ! namprd21 ! prod ! outlook ! com
[Download RAW message or body]

Hi Stefan,

We mean FSCTL_QUERY_NETWORK_INTERFACE_INFO, correct. 

I am going to reply 2 more times, as we have created new cases for the updated \
questions below. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open \
                Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific \
Time (US and Canada) Local country phone number found here: \
http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Stefan Metzmacher <metze@samba.org> 
Sent: Thursday, January 4, 2024 8:23 AM
To: Jeff McCashland (He/him) <jeffm@microsoft.com>
Cc: cifs-protocol@lists.samba.org; Microsoft Support <supportmail@microsoft.com>
Subject: [EXTERNAL] Re: 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

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

_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread]