       (.resetReaderIndex buf)
       (let [result (byte-array (.readableBytes send-buf))]
         (.readBytes send-buf result)
-        result))))
+        {::log2/state log-state
+         ::specs/bs-or-eof result}))))
 
 (s/fdef mark-block-sent
         :args (s/cat :state ::specs/state)

          ;; TODO: That.
          send-buf (.order (Unpooled/buffer u)
                           java.nio.ByteOrder/LITTLE_ENDIAN)
          flag-size (calculate-message-data-packet-length-flags block-to-send)]
      (log/debug (utils/pre-log message-loop-name)
                 (str "Building a Message Block byte array for message "
                      next-message-id
                      "\nTotal length: " u
                      "\nSize | Flags: " flag-size
                      "\nStart Position: " start-pos))

      ;; Q: Is this worth switching to shared/compose?
      (.writeInt send-buf next-message-id)


;;;                the write to FD9 at offset +7, which is the
;;;                len/16 byte.
;;;                So everything else is shifted right by 8 bytes
    (let [q (next-block-queue outgoing)
          current-message (first q)
          ;; This is where message correlation would be
          ;; a good thing, at least for new messages.
          ;; Really should pull pull all the bytes we can
          ;; send (which depends on whether :client-waiting-on-response
          ;; in :flow-control has been delivered) from q.
          ;; Although that consolidation probably doesn't make a lot
          ;; of sense here
          ;; TODO: make that happen
          log-state (log2/debug log-state
                                label
                                "Next message source"
                                {::next-block-queue-size (count q)
                                 ::specs/next-block-queue next-block-queue
                                 ::specs/outgoing outgoing})
          transmission-count (::specs/transmissions current-message)
          _ (assert transmission-count
                    (str pre-log
                         "Missing ::transmissions under "
                         next-block-queue
                         " for "
                         current-message))
          ;; Q: How much time could I save right here and now by making
          ;; state transient?
          ;; (possibly using something like proteus)
          next-message-id (let [n' (inc current-message-id)]
                            ;; Stupid unsigned math
                            ;; Actually, this seems even more problematic
                            ;; than it looks at first glance.
                            ;; Really shouldn't be reusing IDs.
                            ;; Q: Does that matter?
                            (if (<= n' shared-K/max-32-int)
                              (if (= 0 n')
                                1
                                n')
                              (dec (- shared-K/max-32-int))))
          ;; It's tempting to pop that message off of whichever queue is its current home.
          ;; That doesn't make sense here/yet.
          ;; Either we're resending a previous message that never got ACK'd (in which
          ;; case it must stay exactly where it is until we *do* get an ACK), or we're
          ;; sending a new message.
          ;; If it's the latter, it *does* need to move from the un-sent queue to the
          ;; un-ackd queue.
          ;; But that's an operation to handle elsewhere.
          _ (assert current-message)
          ;; It's tempting to try to re-use a previously sent message ID for a re-send.
          ;; After all, if I send message 39, then resend it as message 50, then get
          ;; an ACK for message 39, the only way I have to correlate that to message
          ;; 50 is the stream address.
          ;; Which should be good enough.
          ;; And this seems like a better way to debug messages on the wire.
          ;; And this is the way the reference implementation works.
          state' (assoc-in state [::specs/outgoing ::specs/next-message-id] next-message-id)
          updated-message (-> current-message
                              (update ::specs/transmissions inc)
                              (assoc ::specs/time recent)
                              (assoc ::specs/message-id current-message-id))
          log-state (log2/debug log-state
                                label
                                "Getting ready to build message block for message"
                                {::specs/next-message-id next-message-id
                                 ::based-on updated-message})
          {buf ::specs/bs-or-eof
           log-state ::log2/state} (build-message-block-description log-state
                                                                    updated-message)
          ;; Reference implementation waits until after the actual write before setting any of
          ;; the next pieces. But it's a single-threaded process that's going to block at the write,
          ;; and this part's purely functional anyway. So it should be safe enough to set up
          ;; this transition here
          result (update state'
                         ::specs/outgoing
                         (fn [cur]
                           (assoc cur
                                  ;; Q: Is it really worth tracking this separately?
                                  ;; A: Yes, absolutely.
                                  ;; It *is* readily available in un-ackd-blocks,
                                  ;; until the last block gets ACK'd.
                                  ::specs/last-block-time recent
                                  ;; Note that send-buf is just a byte-array that's
                                  ;; ready to send to the parent.
                                  ;; It's very tempting to make it a queue or set,
                                  ;; and then buffer the sends. But that's half the
                                  ;; point behind the message "package."
                                  ;; This is the culmination of that buffer/send
                                  ;; process.
                                  ;; It cannot matter whether we send duplicates
                                  ;; or a packet gets sent out of order:
                                  ;; our "parent" does not care, and the other
                                  ;; side has to cope with those problems anyway,
                                  ;; since we're using UDP (that's the other half
                                  ;; of the point)
                                  ::specs/send-buf buf
                                  ::specs/want-ping ::specs/false)))
          result (assoc result
                        ::log2/state
                        (log2/debug log-state
                                    label
                                    "Next block built and control state updated to"
                                    {::log2/state result}))]
      ;; It's tempting to split this part up to avoid the conditional.
      ;; Maybe turn the call into a multimethod.
      ;; The latter would be a mistake, since there are
      ;; really only 2 possibilities (I'm sending a new block or
      ;; resending one that had its ACK timeout)
      (if (= ::specs/un-sent-blocks next-block-queue)
        (mark-block-sent result updated-message)
        (mark-block-resent result current-message updated-message)))))

(s/fdef check-for-previous-block-to-resend
        :args ::specs/state
