You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When multiple payloads being uploaded under one Single Owner Chunk address, the pullsync will not transfer the chunk with newer payload to the downstream.
Nevertheless, the SOC gets marked for syncing each time when a node gets a new payload.
This can lead to Shelling point mismatches.
Expected behavior
All valid versions of a Single Owner Chunk are synchronized in the neighborhood.
Actual behavior
It always synchronizes the first payload that reached upstream even when a new (and different) payload should be transferred.
Steps to reproduce
My tests based on the #4727 gsoc-subscribe branch and I tried to upload different payloads from one node meanwhile another node was listening on the /gsoc/subscribe/{address} websocket endpoint.
In order to carry out this manual testing easily, I used the GSOC JS library.
gsoc=require('./dist/index.js')is=newgsoc.InformationSignal('http://localhost:1633',{postageBatchId: '69650e45a19fe3a625b73ef69cf586f6209ff3588e012a05c8e50072a7e39263'})is.write('Hello there!')is.write('This is a really important and uplifting message. I hope you will receive it!')
Possible solution
Reserve chunk-get should be able to retrieve chunk satisfying optional postageBatchHash parameter.
The text was updated successfully, but these errors were encountered:
Context
most recent master branch
fdp-play 5 nodes
Summary
When multiple payloads being uploaded under one Single Owner Chunk address, the pullsync will not transfer the chunk with newer payload to the downstream.
Nevertheless, the SOC gets marked for syncing each time when a node gets a new payload.
This can lead to Shelling point mismatches.
Expected behavior
All valid versions of a Single Owner Chunk are synchronized in the neighborhood.
Actual behavior
It always synchronizes the first payload that reached upstream even when a new (and different) payload should be transferred.
Steps to reproduce
My tests based on the #4727 gsoc-subscribe branch and I tried to upload different payloads from one node meanwhile another node was listening on the
/gsoc/subscribe/{address}
websocket endpoint.In order to carry out this manual testing easily, I used the GSOC JS library.
receiver node:
sender node:
Possible solution
Reserve chunk-get should be able to retrieve chunk satisfying optional postageBatchHash parameter.
The text was updated successfully, but these errors were encountered: