This service is moving soon to a new server. If you see this message, you're unlucky. Should move within 24 hours.

  1. 25 Sep, 2022 7 commits
  2. 24 Sep, 2022 11 commits
    • CalDescent's avatar
      46812184
    • CalDescent's avatar
      Fixed bug which required a node to hold local trade presences before it would request any. · 5c746f0b
      CalDescent authored
      This caused large gaps with no presence data. They are removed when they expire, causing the local count to drop to zero, and the node would only start requesting them again once a peer had pushed one or more entries proactively.
      5c746f0b
    • CalDescent's avatar
      Moved error to debug, as we now get a burst of these soon after startup, due to commit 99858f37. · 309f27a6
      CalDescent authored
      This also shows that commit 99858f37 now prevents a block candidate with a very small number of online accounts being built immediately after startup.
      309f27a6
    • CalDescent's avatar
      Fixed Synchronizer.getBlockSummaries() which was expecting BLOCK_SUMMARIES,... · d2ebb215
      CalDescent authored
      Fixed Synchronizer.getBlockSummaries() which was expecting BLOCK_SUMMARIES, but updated peers send BLOCK_SUMMARIES_V2
      d2ebb215
    • CalDescent's avatar
      Fixed error in rebase. · 7a60f713
      CalDescent authored
      7a60f713
    • CalDescent's avatar
      e80dd31f
    • catbref's avatar
      Initial work on BLOCK_SUMMARIES_V2, part of a bigger arc to improve synchronization. · 94cdc101
      catbref authored
      Touches quite a few files because:
      
      * Deprecate HEIGHT_V2 because it doesn't contain enough info to be fully useful during sync.
      Newer peers will re-use BLOCK_SUMMARIES_V2.
      
      * For newer peers, instead of sending / broadcasting HEIGHT_V2,
      send top N block summaries instead, to avoid requests for minor reorgs.
      
      * When responding to GET_BLOCK, and we don't actually have the requested block,
      we currently send an empty BLOCK_SUMMARIES message instead of not responding,
      which would cause a slow timeout in Synchronizer.
      
      This pattern has spread to other network message response code,
      so now we introduce a generic 'unknown' message type for all these cases.
      
      * Remove PeerChainTipData class entirely and re-use BlockSummaryData instead.
      
      * Each Peer instance used to hold PeerChainTipData - essentially single latest block summary - but now holds a List of latest block summaries.
      
      * PeerChainTipData getter/setter methods modified for compatibility at this point in time.
      
      * Repository methods that return BlockSummaryData (or lists of) now try to fully populate them,
      including newly added block reference field.
      
      * Re-worked Peer.canUseCommonBlockData() to be more readable
      
      * Cherry-picked patch to Message.fromByteBuffer() to pass an empty, read-only ByteBuffer to subclass fromByteBuffer() methods, instead of null.
      This allows natural use of BufferUnderflowException if a subclass tries to use read(), or hasRemaining(), etc. from an empty data-payload message.
      Previously this could have caused an NPE.
      94cdc101
    • CalDescent's avatar
      Moved various online accounts logs to TRACE level, to make it easier to... · 863a5eff
      CalDescent authored
      Moved various online accounts logs to TRACE level, to make it easier to monitor the queue processing when in DEBUG.
      863a5eff
    • CalDescent's avatar
      Modified online accounts request interval, and introduced bursting. · 5b81b309
      CalDescent authored
      It will now request online accounts every 1 minute instead of every 5 seconds, except for the first 5 minutes following a new online accounts timestamp, in which it will request every 5 seconds (referred to as the "burst" interval). It will also use the burst interval for the first 5 minutes after the node starts.
      
      This is based on the idea that most online accounts arrive soon after a new timestamp begins, and so there is no need to request accounts so frequently after that. This should reduce data usage by a significant amount.
      
      Once mempow is fully rolled out, the "burst" feature can be reduced or removed, since online accounts will be sent ahead of time, generally 15-30 mins prior to the new online accounts timestamp becoming active.
      5b81b309
    • CalDescent's avatar
      Add accounts from the import queue individually, and then skip future... · 174a779e
      CalDescent authored
      Add accounts from the import queue individually, and then skip future duplicates before unnecessarily validating them again.
      
      This closes a gap where accounts would be moved from onlineAccountsImportQueue to onlineAccountsToAdd, but not yet imported. During this time, there was nothing to stop them from being added to the import queue again, causing duplicate validations.
      174a779e
    • CalDescent's avatar
  3. 23 Sep, 2022 5 commits
  4. 20 Sep, 2022 2 commits
  5. 19 Sep, 2022 3 commits
  6. 17 Sep, 2022 5 commits
  7. 16 Sep, 2022 1 commit
  8. 11 Sep, 2022 3 commits
  9. 10 Sep, 2022 3 commits