Reply to "wants" messages with "has" messages #12
Conversation
| // Remote: pub.Identity(), | ||
| // Address: network2.NewAddress("one.planetary.pub:8008"), | ||
| //} | ||
| //myPatchwork = refs.MustNewIdentity("@qFtLJ6P5Eh9vKxnj7Rsh8SkE6B6Z36DVLP7ZOKNeQ/Y=.ed25519") |
There was a problem hiding this comment.
Not important, this whole file is just a test program not used in production.
| @@ -0,0 +1,29 @@ | |||
| package replication | |||
There was a problem hiding this comment.
Most of the code in this file was moved here from other files.
| downloader Downloader | ||
| logger logging.Logger | ||
|
|
||
| // todo cleanup processes |
There was a problem hiding this comment.
I think this can be done later, it could even stay like this all the way to production unless we ran the app for a very long time.
There was a problem hiding this comment.
As I understand the underlying process goroutines for incoming and outgoing loops will get terminated on connection context termination anyway, right? So the only thing we'd have to improve would be reacting to connection termination by deleting the process struct from this map (for example by running a goroutine awaiting ctx close while creating a new process in getOrCreateProcess). Do I understand the problem correctly?
I'm actually ok with leaving it as it is if that's only about cleaning up the process struct. As I can imagine the map won't grow huge in our normal use case.
| wl, err := p.wantListStorage.GetWantList() | ||
| if err != nil { | ||
| p.logger.WithError(err).Error("could not get the want list") | ||
| continue | ||
| } | ||
|
|
||
| for _, v := range wl.List() { |
There was a problem hiding this comment.
I think that we are missing dropping a blob from the wants list once we fetch it. That means we will always tell all our peers about all of our wants what is not optimal I guess. Should we add this to the todo list in #1?
There was a problem hiding this comment.
I added this to #1. The want list has to be redone in general, it is completely temporary.
This implements replying to "wants" messages with "has" messages. "Wants" messages are received through
blobs.createWantsstream initiated by the local node and have to trigger a reply with a "has" message throughblobs.createWantsstream initiated by the remote node.