TODO.multi-channel

   1 TODOs for multi-channel
   2 =======================
   3
   4 - create replay:
   5   --------------
   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...
  14
  15   e.g.:
  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
  19
  20
  21 - channel sequence number
  22   -----------------------
  23
  24   - overflow handling ...
  25
  26
  27 - preview-diff doc ms-smb2, june22:
  28   p 297, create validation:
  29
  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
  33   request."
  34
  35 - test / find / fix: dgram messaging send hangs for data (iov) of 30K
  36
  37 - in session bind: verify same clientGUID and smb dialect as existing sessions
  38
  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?
  43   !!
  44   !! The new diff doc (June22) is at least inconsistent in that
  45   !! it removes the ClientGUID from the lease-identifyer....
  46   !!
  47   !! ==> Currently in clarification.
  48
  49 - index for CreateGUID->smbXsrv_open entry to support create replay
  50
  51
  52 - oplock breaks (replay):
  53   ----------------------
  54
  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.
  62
  63   => possibility: watch TCP state to verify
  64   => have (hack) patch in the tree
  65      (using IPPROTO_TCP TCP_INFO ...)
  66      TODO: do better (?)
  67      how portable is this? ((Free)BSD, *solaris)
  68   => possibly implement support for IPPROTO_TCP TCP_INFO
  69      in socket wrapper to test it
  70
  71   possibly at first without IPPROTO ... :
  72
  73   - send oplock/lease break
  74   - start timer
  75   - remember current tcp sequence number
  76   - disable timer if oplock/lease break reply comes in
  77   - if timer expires:
  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
  81
  82
  83 - interface characteristics:
  84   --------------------------
  85
  86   how to do it?
  87   - ethtool-like for linux
  88     ==> DONE
  89   - bsd/solaris
  90   - smb.conf option (interfaces = IP:bw)
  91     ==> DONE
  92
  93 - clustering/ctdb:
  94   ---------------
  95
  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.
 100
 101   - QUESTIONS:
 102
 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?
 110
 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
 117
 118
 119
 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
 123
 124   TODO: verify
 125
 126
 127 tests:
 128
 129 - multi-channel support in smbclient?
 130
 131 - torture-test:
 132
 133   - smbtorture bench
 134   - # channels -> open channels
 135   - file: size = (#channels) * chunk-size (8mb) [ or chunk-size ]
 136   - open
 137   - read on each channel in a loop
 138   - async smbXcli_read .... for each channel (in event-loop)
 139
 140   - alterantively:
 141   - open conn
 142   - open file
 143   - make #channel forks
 144   - create channel in child
 145   - (only possibly problematic if using encryption,
 146      could give each connection/client nonce offset)