1 TODOs for multi-channel
2 =======================
6 Questions: (==> torture tests)
7 - are fields / create contexts of the replayed request
8 checked against the original request?
9 ==> partly covered by tests
10 - do differences lead to errors?
11 ==> partly covered by tests
12 - what is used to compose the reply to the replayed create?
13 original request or replayed requetst...
16 - original request had a batch lease, but replayed has a read lease
17 - original request has different access mask than replayed one
18 - original request has different share mode than replated one
21 - channel sequence number
22 -----------------------
24 - overflow handling ...
27 - preview-diff doc ms-smb2, june22:
28 p 297, create validation:
30 "If CreateOptions includes FILE_NO_INTERMEDIATE_BUFFERING and
31 DesiredAccess includes FILE_APPEND_DATA, the server MUST set
32 FILE_APPEND_DATA to zero in the DesiredAccess field in the
35 - test / find / fix: dgram messaging send hangs for data (iov) of 30K
37 - in session bind: verify same clientGUID and smb dialect as existing sessions
39 !! According to latest comments and preview docs by Microsoft,
40 !! is the ClientGUID reliable enough to be used by us for the
41 !! purpose of pro-actively moving connections to an smbd that
42 !! is already serving connections from the same GUID?
44 !! The new diff doc (June22) is at least inconsistent in that
45 !! it removes the ClientGUID from the lease-identifyer....
47 !! ==> Currently in clarification.
49 - index for CreateGUID->smbXsrv_open entry to support create replay
52 - oplock breaks (replay):
53 ----------------------
55 when we send oplock/lease break,
56 then we need to make sure that the client receives it.
57 problematic case is when a channel failure occurs
58 while we send this out. The client may not have
59 received it (in which case we need to retry on a diffrent
60 channel), or it may have sent out the ACK on a different
61 channel, in which case we are good.
63 => possibility: watch TCP state to verify
64 => have (hack) patch in the tree
65 (using IPPROTO_TCP TCP_INFO ...)
67 how portable is this? ((Free)BSD, *solaris)
68 => possibly implement support for IPPROTO_TCP TCP_INFO
69 in socket wrapper to test it
71 possibly at first without IPPROTO ... :
73 - send oplock/lease break
75 - remember current tcp sequence number
76 - disable timer if oplock/lease break reply comes in
78 check acknowledged tcp seq num vs remebered one
79 if remembered one is not acknowledged, consider
80 channel broken and resend break request on other channel
83 - interface characteristics:
84 --------------------------
87 - ethtool-like for linux
90 - smb.conf option (interfaces = IP:bw)
96 - MC addresses should not be ctdb public addresses
97 - for clustering = yes, each IF should have a static IP address in addition
98 to the public ones, only the static ones would get listed in the
99 query interfaces response.
103 - what happens if an initial connection is made through a
104 ctdb public address, and then a network interface info
105 ioctl is received? --> only reply with the single
106 public address for this? and only give more addresses
107 in the ioctl reply if the initial request was done
108 through a static address?
109 ==> doesn't this invalidate the ctdb clustering concept to an extend?
111 - What happens if a session bind is done on a connection
112 that was NOT provided as part of a query network interface info
113 response? If this is allowed, we have a fundamental problem
114 because clients can try to bind to any address that belongs
115 to the node, or even to the cluster.
116 ==> danger of node-spanning MC-sessions
120 - session bind vs. previous_session_id:
121 doc (3.3.5.5 and 3.3.5.5.3) seems to imply
122 that session reconnect at session bind is OK
129 - multi-channel support in smbclient?
134 - # channels -> open channels
135 - file: size = (#channels) * chunk-size (8mb) [ or chunk-size ]
137 - read on each channel in a loop
138 - async smbXcli_read .... for each channel (in event-loop)
143 - make #channel forks
144 - create channel in child
145 - (only possibly problematic if using encryption,
146 could give each connection/client nonce offset)