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

SOC pullsync with different payloads #4739

Closed
nugaon opened this issue Jul 26, 2024 · 1 comment
Closed

SOC pullsync with different payloads #4739

nugaon opened this issue Jul 26, 2024 · 1 comment
Assignees
Labels
needs-triaging new issues that need triaging

Comments

@nugaon
Copy link
Member

nugaon commented Jul 26, 2024

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:

gsoc = require('./dist/index.js')
is = new gsoc.InformationSignal('http://localhost:11633')
cancelSub = is.subscribe({onMessage: msg => console.log('gsoc-pull-sync', msg), onError: console.log})

sender node:

gsoc = require('./dist/index.js')
is = new gsoc.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.

@nugaon nugaon added needs-triaging new issues that need triaging good first issue Good for newcomers and removed good first issue Good for newcomers labels Jul 26, 2024
@nikipapadatou
Copy link
Collaborator

included in the GSOC solution in 2.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triaging new issues that need triaging
Projects
None yet
Development

No branches or pull requests

2 participants