1. 12 Apr, 2023 5 commits
    • Kirill Smelkov's avatar
      . · 324dcb15
      Kirill Smelkov authored
      324dcb15
    • Kirill Smelkov's avatar
      fixup! Y client: Fix URI scheme to move credentials out of query · 7d1daf15
      Kirill Smelkov authored
      parse_qsl no longer treats ';' as valid query separator for security
      reason because most proxies did not do so and it was possible to poison
      proxy cache due to difference in query separator handling (see bugs.python.org/issue42967).
      
      To handle credentials we don't have any proxy here, and it is still
      perfectly valid to use ';' as credentials separator.
      
      -> Fix it with ';' -> '&' replace workaround, before feeding credentials
      string to parse_qsl.
      
      Amends: b9a42957.
      7d1daf15
    • Kirill Smelkov's avatar
      client: Fix URI scheme to move credentials out of query · 2bc2ba14
      Kirill Smelkov authored
      - Move ca/cert/key out of query part into credentials part of URL
      - As a consequence move cluster name out of credentials part into path part
      - Allow both neo:// and neos:// schemes to be used.
        neo:// means always without SSL and neos:// means always with SSL.
        Even if neos:// URL comes without credentials embedded into it - they
        can be obtained from elsewhere.
      
      I need this change in wendelin.core 2 which needs to take a zurl and
      compute a mountpoint patch that corresponds to it, so that multiple
      several zopes that use the same NEO storage, could be associated with
      the same single WCFS instance.
      2bc2ba14
    • Kirill Smelkov's avatar
      Connection: Adjust msg_id a bit so it behaves like stream_id in HTTP/2 · ac3a4d13
      Kirill Smelkov authored
      This is 2020 edition of my original patch from 2016 ( kirr/neo@dd3bb8b4 ).
      
      It was described in my NEO/go article ( https://navytux.spb.ru/~kirr/neo.html )
      in the text quoted below:
      
          Then comes the link layer which provides service to exchange messages over
          network. In current NEO/py every message has `msg_id` field, that similarly to
          ZEO/py marks a request with serial number with requester then waiting for
          corresponding answer to come back with the same message id. Even though there
          might be several reply messages coming back to a single request, as e.g. NEO/py
          asynchronous replication code[0], this approach is still similar to ZEO/py
          remote procedure call (RPC) model because of single request semantic. One of
          the places where this limitation shows is the same replicator code where
          transactions metadata is fetched first with first series of RPC calls, and only
          then object data is fetched with the second series of RPC calls. This could be
          not very good e.g. in case when there is a lot of transactions/data to
          synchronize, because 1) it puts assumption on, and so constraints, the storage
          backend model on how data is stored (separate SQL tables for metadata and
          data), and 2) no data will be synchronized at all until all transactions are
          synchronized first. The second point prevents for example the syncing storage
          in turn to provide, even if read-only, service for the already fetched data.
          What would be maybe more useful is for requester to send request that it wants
          to fetch ZODB data in `tid_min..tid_max` range and then the sender sending
          intermixed stream of metadata/data in zodbdump-like format.
      
          Keeping in mind this, and other examples, NEO/go shifts from thinking about
          protocol logic as RPC to thinking of it as more general network protocol and
          settles to provide general connection-oriented message exchange service[1] :
          whenever a message with new `msg_id` is sent, a new connection is established
          multiplexed on top of a single node-node TCP link. Then it is possible to
          send/receive arbitrary messages over back and forth until so established
          connection is closed. This works transparently to NEO/py who still thinks it
          operates in simple RPC mode because of the way messages are put on the wire and
          because simple RPC is subset of a general exchange.  The `neonet` module also
          provides `DialLink` and `ListenLink` primitives[2] that work similarly to
          standard Go `net.Dial` and `net.Listen` but wrap so created link into the
          multiplexing layer. What is actually done this way is very similar to HTTP/2
          which also provides multiple general streams multiplexing on top of a single
          TCP connection ([3], [4]).  However if connection ids (sent in place of
          `msg_id` on the wire) are assigned arbitrary, there could be a case when two
          nodes could try to initiate two new different connections to each other with
          the same connection id. To prevent such kind of conflict a simple rule to
          allocate connection ids either even or odd, depending on the role peer played
          while establishing the link, could be used. HTTP/2 takes similar approach[5]
          where `"Streams initiated by a client MUST use odd-numbered stream identifiers;
          those initiated by the server MUST use even-numbered stream identifiers."` with
          NEO/go doing the same corresponding to who was originally dialer and who was a
          listener. However it requires small patch to be applied on NEO/py side to
          increment `msg_id` by 2 instead of 1.
      
          NEO/py currently explicitly specifies `msg_id` for an answer in only limited
          set of cases, by default assuming a reply comes to the last received message
          whose `msg_id` it remembers globally per TCP-link. This approach is error-prone
          and cannot generally work in cases where several simultaneous requests are
          received over single link. This way NEO/go does not maintain any such global
          per-link knowledge and handles every request by always explicitly using
          corresponding connection object created at request reception time.
      
          [0] https://lab.nexedi.com/kirr/neo/blob/463ef9ad/neo/storage/replicator.py
          [1] https://lab.nexedi.com/kirr/neo/blob/463ef9ad/go/neo/neonet/connection.go
          [2] https://lab.nexedi.com/kirr/neo/blob/463ef9ad/go/neo/neonet/newlink.go
          [3] https://tools.ietf.org/html/rfc7540#section-5
          [4] https://http2.github.io/faq/#why-is-http2-multiplexed
          [5] https://tools.ietf.org/html/rfc7540#section-5.1.1
      
      It can be criticized, but the fact is:
      
      - it does no harm to NEO/py and is backward-compatible: a NEO/py node
        without this patch can still successfully connect and interoperate to
        another NEO/py node with this patch.
      
      - it is required for NEO/go to be able to interoperate with NEO/py.
        Both client and server parts of NEO/go use the same neonet module to exchange messages.
      
      - NEO/go client is used by wendelin.core 2, which organizes access to on-ZODB
        ZBigFile data via WCFS filesystem implemented in Go.
      
      So on one side this patch is small, simple and does not do any harm to NEO/py.
      On the other side it is required for NEO/go and wendelin.core 2.
      
      To me this clearly indicates that there should be no good reason to reject
      inclusion of this patch into NEO/py.
      
      --------
      
      My original patch from 2016 came with corresponding adjustments to neo/tests/testConnection.py
      ( kirr/neo@dd3bb8b4 )
      but commit f6eb02b4 (Remove packet timeouts; 2017-05-04) removed testConnection.py
      completely and, if I understand correctly, did not add any other test to
      compensate that. This way I'm not trying to restore my tests to
      Connection neither.
      
      Anyway, with this patch there is no regression to all other existing NEO/py tests.
      
      --------
      
      My original patch description from 2016 follows:
      
      - even for server initiated streams
      - odd  for client initiated streams
      
      This way I will be able to use Pkt.msg_id as real stream_id in go's Conn
      because with even / odd scheme there is no possibility for id conflicts
      in between two peers.
      ac3a4d13
    • Levin Zimmermann's avatar
      Add branch for WC2 compatibility mode · 739096b7
      Levin Zimmermann authored
      Between NEO/go and NEO/py there are various incompatibilities.
      This branch aims to transparently communicate those incompatibilities.
      We can also specify a SR in SlapOS which uses this branch in case
      someone aims to use WC2.
      
      Here we start from the old-proto (e.g. pre-messagepack) branch, because
      in NEO/go msgpack support isn't fully implemented yet. This isn't
      considered as an incompatibility but simply as a remaining TODO on
      NEO/go side.
      739096b7
  2. 11 May, 2021 2 commits
  3. 22 Mar, 2021 1 commit
  4. 19 Aug, 2020 3 commits
    • Julien Muchembled's avatar
      qa: skip broken ZODB test · a1418c9d
      Julien Muchembled authored
      ======================================================================
      FAIL: check_tid_ordering_w_commit (neo.tests.zodb.testBasic.BasicTests)
      ----------------------------------------------------------------------
      Traceback (most recent call last):
        File "ZODB/tests/BasicStorage.py", line 397, in check_tid_ordering_w_commit
          self.assertEqual(results.pop('lastTransaction'), tids[1])
        File "neo/tests/__init__.py", line 301, in assertEqual
          return super(NeoTestBase, self).assertEqual(first, second, msg=msg)
      failureException: '\x03\xd8\x85H\xbffp\xbb' != '\x03\xd8\x85H\xbfs\x0b\xdd'
      
      (cherry picked from commit f4cb59d2)
      a1418c9d
    • Julien Muchembled's avatar
      client: fix race with invalidations when starting a new transaction on ZODB 5 · 96a5c01f
      Julien Muchembled authored
      This requires ZODB >= 5.6.0
      
      (cherry picked from commit a7d101ec)
      96a5c01f
    • Julien Muchembled's avatar
      Code clean-up, comment fixes · fa7fbad6
      Julien Muchembled authored
      (cherry picked from commit 43029be2)
      fa7fbad6
  5. 22 May, 2020 2 commits
    • Julien Muchembled's avatar
      master: fix crash in STARTING_BACKUP when connecting to an upstream secondary master · 011eba12
      Julien Muchembled authored
      This fixes the following assertion:
      
        Traceback (most recent call last):
          File "neo/master/app.py", line 172, in run
            self._run()
          File "neo/master/app.py", line 182, in _run
            self.playPrimaryRole()
          File "neo/master/app.py", line 302, in playPrimaryRole
            self.backup_app.provideService())
          File "neo/master/backup_app.py", line 114, in provideService
            node, conn = bootstrap.getPrimaryConnection()
          File "neo/lib/bootstrap.py", line 74, in getPrimaryConnection
            poll(1)
          File "neo/lib/event.py", line 160, in poll
            to_process.process()
          File "neo/lib/connection.py", line 504, in process
            self._handlers.handle(self, self._queue.pop(0))
          File "neo/lib/connection.py", line 92, in handle
            self._handle(connection, packet)
          File "neo/lib/connection.py", line 107, in _handle
            pending[0][1].packetReceived(connection, packet)
          File "neo/lib/handler.py", line 125, in packetReceived
            self.dispatch(*args)
          File "neo/lib/handler.py", line 75, in dispatch
            method(conn, *args, **kw)
          File "neo/lib/handler.py", line 159, in notPrimaryMaster
            assert primary != self.app.server
        AttributeError: 'BackupApplication' object has no attribute 'server'
      
      (cherry picked from commit dba07e72)
      011eba12
    • Julien Muchembled's avatar
      mysql: workaround for MDEV-20693 · 70387981
      Julien Muchembled authored
      70387981
  6. 07 Jan, 2020 1 commit
  7. 28 Apr, 2019 1 commit
  8. 27 Apr, 2019 12 commits
  9. 26 Apr, 2019 4 commits
  10. 16 Apr, 2019 5 commits
  11. 05 Apr, 2019 3 commits
  12. 01 Apr, 2019 1 commit