GitLab

to emphasize idempotence

comes at the cost of O(n) Blocks() method.

so there's one less name to think about

A nice invariant for bitswap sessions:

        Senders and receivers can trust that messages do not contain
        duplicate blocks or duplicate keys. Backing the message with a
        map enforces this invariant.

        This comes at the cost of O(n) getters.

implementation will be patched to ensure bitswap messages cannot contain
duplicate blocks or keys

@whyrusleeping noticed this a couple days ago

potential long-term fix: prevent duplicate entries in the wantlist by
using a map/set and iterating over this data structure on export

- distinguish log.Error and log.Errorf functions
- Initialize structs with field names
- A bit of unreachable code (defers)

addresses concurrent access in bitswap session

fixes data race detected in a testnet test

![](http://m.memegen.com/77n7dk.jpg)

(that wasn't mine :p)

Important bugfix. Otherwise bitswap cannot message peers
the node has not connected to yet :(

new Service interface

and other logging switches. I kept the u.PErr and u.POut in cli
commands, as those do need to write raw output directly.

We'll want a `type blocks.Block interface {}` later, but
for now, make sure Blockstore uses ptrs for both Get and Put.

+ fix NewBlock output compile error

Rather than pushing errors back down to lower layers, propagate the
errors upward.

This commit adds a `ReceiveError` method to BitSwap's network receiver.

Still TODO: rm the error return value from:

    net.service.handler.HandleMessage

This is inspired by delegation patterns in found in the wild.

sending

true -> always send to peer

false -> use ledger-based strategy described in IPFS paper draft 3