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
Rhizome now seems to have problems with bigger files sometimes not transmitting them even after 8 hours of idling. MeshMS are also not propagating every time, the sender has them in his store but doesn't send them to his direct neighbour. Since it's also using rhizome maybe they are related. Peer count says that the topology is complete and everything else seems to work.
I compared the latest commit dced3bb which seems to have the problem with batphone-release-0.93, there everything works as expected. We tested in core-network and in our qemu based emulation environment.
The text was updated successfully, but these errors were encountered:
If you turn on debug.rhizome_sync_keys, you should see that both nodes will repeatedly log the list of bundles that are missing / extra. But currently if a transfer stops for some reason, it will never be restarted.
We need to work out the reason why these bundles are stopping or being rejected.
I'm guessing this issue is also related to rhizome database locking.
Rhizome now seems to have problems with bigger files sometimes not transmitting them even after 8 hours of idling. MeshMS are also not propagating every time, the sender has them in his store but doesn't send them to his direct neighbour. Since it's also using rhizome maybe they are related. Peer count says that the topology is complete and everything else seems to work.
I compared the latest commit dced3bb which seems to have the problem with batphone-release-0.93, there everything works as expected. We tested in core-network and in our qemu based emulation environment.
The text was updated successfully, but these errors were encountered: