-
Notifications
You must be signed in to change notification settings - Fork 112
Should the client repeat the broadcast block request? #65
Comments
This sounds like a bug. It could be related to #51 but I'm not sure. However, in general, I agree. We may want to occasionally rebroadcast existing wantlists to all peers (we used to but I'm not sure if we do anymore). Ideally, we wouldn't have to but bugs happen. |
So, you're saying you have two connected nodes and one isn't giving data to the other? |
Yea that makes sense. I'm not sure it'd be #51 cause it sounds like node B and node A are connected over a long period of time. But that is still of concern Also though I really want to get BS latest published, cause I can't even tell if this is with sessions code or the 0.4.18 BS, which didn't actually use sessions at all. |
@Stebalien yes, the process of sending data is blocked on several data blocks, and each time it is reproduced, it is caused by different data blocks. The corresponding I added the code to rebroadcast the blocking block and I was finally able to get the resources. The test code is as follows://workers.go
func (bs *Bitswap) rebroadcastWorker(parent context.Context) {
...
lastwl := struct {
count int
blocks map[cid.Cid]struct{}
}{}
for {
log.Event(ctx, "Bitswap.Rebroadcast.idle")
select {
case <-tick.C:
n := bs.wm.wl.Len()
if n > 0 {
log.Debug(n, " keys in bitswap wantlist")
}
if n == 0 {
break
}
snapshoot := lastwl
lastwl.count = n
lastwl.blocks = make(map[cid.Cid]struct{}, n)
for _, entry := range bs.wm.wl.Entries() {
lastwl.blocks[entry.Cid] = struct{}{}
}
if snapshoot.count != n {
break
}
diff := false
for c := range snapshoot.blocks {
if _, ok := lastwl.blocks[c]; !ok {
diff = true
break
}
}
if diff {
break
}
msg := bsmsg.New(false)
for _, entry := range bs.wm.wl.Entries() {
if !entry.Trash {
msg.AddEntry(entry.Cid, entry.Priority)
}
}
for p, q := range bs.wm.peers {
q.resendMessage(msg)
log.Warningf("rebroadcast wantlist to peer %s", p.Pretty())
}
...
}
}
} //wantmanager.go
func (mq *msgQueue) resendMessage(msg bsmsg.BitSwapMessage) {
var work bool
mq.outlk.Lock()
defer func() {
mq.outlk.Unlock()
if !work {
return
}
select {
case mq.work <- struct{}{}:
default:
}
}()
if mq.out == nil {
mq.out = bsmsg.New(false)
}
for _, e := range msg.Wantlist() {
if !e.Cancel {
work = true
mq.out.AddEntry(e.Cid, e.Priority)
}
}
} |
@hannahhoward I don't think it's because #51, these two nodes are already connected. The // Connected/Disconnected warns bitswap about peer connections
func (bs *Bitswap) PeerConnected(p peer.ID) {
bs.wm.Connected(p)
bs.engine.PeerConnected(p)
} func (pm *WantManager) startPeerHandler(p peer.ID) *msgQueue {
mq, ok := pm.peers[p]
if ok {
mq.refcnt++
return nil
}
mq = pm.newMsgQueue(p)
// new peer, we will want to give them our full wantlist
fullwantlist := bsmsg.New(true)
for _, e := range pm.bcwl.Entries() {
for k := range e.SesTrk {
mq.wl.AddEntry(e, k)
}
fullwantlist.AddEntry(e.Cid, e.Priority)
}
mq.out = fullwantlist
mq.work <- struct{}{}
pm.peers[p] = mq
go mq.runQueue(pm.ctx)
return mq
} |
According to the following code, I think that even if the server node has the corresponding resources, it will cause the transmission failure due to the network in response to the data block, such as Lines 107 to 110 in 916de59
I think it is necessary to detect blocked data block requests and rebroadcast them when they are idle. |
scene
I have two nodes, which are in different LANs. They use a server on the public network for port forwarding, so that the two nodes are connected. The connection network bandwidth is about 5M and it is not very stable.
The A node has a resource of about 200M. When the Node B obtains the resource through the ipfs gateway, it will block on some data blocks and cannot obtain data.
The
wantlist
of node A is always holdhash
of these data blocks, and theledger
of node B also haswantlist
for node A, indicating that node B has received all data block requests, but for some reason The Node B does not send the data block to the A node, causing the A node to wait for the response of these data blocks.If the A node can repeat the request to broadcast these data blocks, the B node can respond correctly when it receives the data block request again.
I am using ipfs private network
my point of view
The client should repeatedly broadcast long waiting data block requests. In order to solve the problem that the nearby nodes have resources but cannot be quickly obtained.
The text was updated successfully, but these errors were encountered: