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
  84   - remember sent and not acked oplock break requests
  85     in a list (on the smbXsrv_connection or so)
  86   - for each such request, start a timer when putting
  87     it into the list
  88   - develop an arithmetic and a mechanism using the SIOCOUTQ
  89     ioctl (checked at every I/O on the interface)
  90     to detect when a packet has really left the host.
  91   - if the algo says that the packet has been sent,
  92     disable timer and remove it from the list.
  93     ==> really?
  94         what about 'left the host' vs. 'ack has been received'?
  95   - if oplock break reply arrives, disable timer and remove
  96     pkt from list.
  97   - if timer expires, consider channel broken and
  98     resend break on other channel
  99
 100   ===========================================
 101
 102
 103 - interface characteristics:
 104   --------------------------
 105
 106   how to do it?
 107   - ethtool-like for linux
 108     ==> DONE
 109   - bsd/solaris
 110   - smb.conf option (interfaces = IP:bw)
 111     ==> DONE
 112
 113 - clustering/ctdb:
 114   ---------------
 115
 116   - MC addresses should not be ctdb public addresses
 117   - for clustering = yes, each IF should have a static IP address in addition
 118     to the public ones, only the static ones would get listed in the
 119     query interfaces response.
 120
 121   - QUESTIONS:
 122
 123     - what happens if an initial connection is made through a
 124       ctdb public address, and then a network interface info
 125       ioctl is received? --> only reply with the single
 126       public address for this? and only give more addresses
 127       in the ioctl reply if the initial request was done
 128       through a static address?
 129       ==> doesn't this invalidate the ctdb clustering concept to an extend?
 130
 131     - What happens if a session bind is done on a connection
 132       that was NOT provided as part of a query network interface info
 133       response? If this is allowed, we have a fundamental problem
 134       because clients can try to bind to any address that belongs
 135       to the node, or even to the cluster.
 136       ==> danger of node-spanning MC-sessions
 137
 138
 139
 140 - session bind vs. previous_session_id:
 141   doc (3.3.5.5 and 3.3.5.5.3) seems to imply
 142   that session reconnect at session bind is OK
 143
 144   TODO: verify
 145
 146
 147 tests:
 148
 149 - multi-channel support in smbclient?
 150
 151 - torture-test:
 152
 153   - smbtorture bench
 154   - # channels -> open channels
 155   - file: size = (#channels) * chunk-size (8mb) [ or chunk-size ]
 156   - open
 157   - read on each channel in a loop
 158   - async smbXcli_read .... for each channel (in event-loop)
 159
 160   - alterantively:
 161   - open conn
 162   - open file
 163   - make #channel forks
 164   - create channel in child
 165   - (only possibly problematic if using encryption,
 166      could give each connection/client nonce offset)