Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

car-mirror: Edge cases of receiving blocks you already have possible #32

Open
matheus23 opened this issue Jun 29, 2023 · 2 comments
Open

Comments

@matheus23
Copy link
Member

Came up in a meeting with @expede: There does exist an edge case where CAR mirror will send blocks that the recipient already has, even outside the cold call.

Specifically, if the receiver has a disjoint graph root that it doesn't know is connected to the DAG they're requesting, then the batch from the sender may contain blocks from that previously disjoint graph root.

E.g. a simple (and admittedly weird) case where the receiver has every second block in a blockchain and is asking for the root.
The sender will respond with a certain depth of the blockchain. Every second of these blocks will be redundant.

So in some cases bitswap will actually be 'more precise'. But the same can be said of CAR mirror in the mode without a bloomfilter.


Mostly I filed this for @expede to go through the spec in case there's any mention of never sending a block the receiver already has.

@expede
Copy link
Member

expede commented Aug 3, 2023

I'm trying to load this back into my brain after being on vacation for 2 weeks.

I think graphically, this looks something like this:

flowchart TB
    a -.-> b -.-> c -.-> d -.-> e

    subgraph Want
      a
      b
      d
    end

    subgraph Have

      y --> c
      y --> e
    end
Loading

A cold call can absolutely give you redundant blocks, because it doesn't have enough info yet — and that's covered in the prose.

For the other case, I don't know if you do get redundant blocks, but you're going to have more overhead (blooms etc) than BitSwap in this weird striped edge case. We currently assume that if you have c, then you also have d and e (recursively). It's possible for this to not be the case.

I think that we probably won't include redundant blocks in this case, since they get caight by the bloom. Rather, it will send lots of small results back, and have to do a lot of round trips. I feel like I'm missing something in here — since I was pretty convinved (but also very tired) right before I went on vacation — so I'll think on it more.

@matheus23
Copy link
Member Author

matheus23 commented Aug 4, 2023

In your example, let's assume the sender only sends "a" in the cold call, and then in the second call, it sends "b" and "c".
The receiver didn't know that they had to put "c" into the bloomfilter between these calls. It tried to walk what it had already, starting from the "a" block, but couldn't find anything, so the bloomfilter was empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants