Upgrade issue

[chillicane]

Im in the process of upgrading ~165 btsync installs from 1.1.15 to 1.1.48. All of the 'client' endpoints have readonly keys to sync the data from the 'server' side - the idea being they can share the actual load of transferring bits amongts themselves.

Unfortunatley, so far at least, the 'client' endpoints are only connecting to the 'server' device and not each other - they are not showing each other in their respective devices tab.

This was working prior to the upgrade and ive made no configuration changes during the process.

Any ideas?

[Harold Feit]

1.1.48 clients can't talk to 1.1.15 clients.

What part of the upgrade have you completed so far?

[chillicane]

Yes i understand that - im talking about the 30 odd endpoints ive already upgraded are not talking to each other.

In a genius move i tried deleting some of the settings files on my install here and lost my keys, which of course i had neglected to back up anywhere so it looks like i'll be starting again anyway.

Rookie mistake and boy do i feel stupid. Anyway, after re-adding a few i checked and they appear to be syncing better now so im guessing its the data in sync.dat isnt being refreshed properly when i run the new binary.

Moot point now coz ill have to re-add them all. It would be nice do have 1 file that has peer caching seperate to the file that has shared folder data so we can flush the peer data without removing the shared folder data.

[goli]

Hey there.

Are you sure this has worked before? Ok, having 165 setups tells me you might have noticed this earlier. But when I used 1.0.x I tried to setup kind of a backup node which only gets a read-only secret. As its task as backup only node this did work, but the backup only node wasn't able to provie the other nodes with changed data, even if the changes weren't introduced by the backup node but by another node which did have a write key. So pretty much the same thing you discovered: Read-only nodes can not distribute any files, even not for relay purpose.

If I'm wrong, I would be glad to know because that currently is the only thing which is not pretty nice.

But to discover what happens: Maybe the read-only nodes don't connect to any tracker as providers and do not send out any broadcasts? What if you add one read-only node as known host to another read-only node? Still the same?

That's the very sport where I stopped thinking about syncing with read-only nodes and just provide write secrets, back then .

Regards,

Stephan.

[chillicane]

This stuff gets really tricky to discuss without a diagram but here goes.

My read only nodes were only supposed to ever recieve data - not send it, check. Other nodes were definetly able to replicate thru nodes which only had a read only key.

What might be different in my case was that all nodes have access to my 'main server' which theoritically should have a complete list of all peers which it will share with all other peers so they can, um...., find peers!

Each read only share had an entry in 'use predefined hosts' which points back to my 'main server' so it should always be contactable. Also once an initial peer listing has been garnered even if there is a break in communications somewhere, each peer should be able to reconstruct a compelte list from all the other peers.

But that initial sync of peer listsings comes from the 'main server'

Make sense? Are we even talking about the same thing? Boy i hope so coz its starting to give me a headache!

[goli]

Hmm. That's some very special and detailed thing. So I guess we need some staff here that answers protocol questions. Or refuses to answer those in the current state of the software. But this most likely isn't publicly available information.

I don't think that nodes do provide other nodes with node lists. I haven't seen a single node doing so.

A small setup that would show this if it would be implemented:

• completely disabled tracker servers and LAN discovery, only known hosts
  
• network A contains an Ubuntu node having a private IP and static port-forwarding and a Windows 7 node without static port-forwarding but wth enabled UPNP.
  
• network B contains two Windows 7 nodes with disabled UPNP but with enabled LAN discovery
  
• All three Windows 7 nodes know the Ubuntu node as "known host" (the public IP/port which is forwareded)
  
• All three WIndows 7 nodes see the Ubuntu node
  
• The two Windows 7 nodes on network B know each other, most likely through LAN discovery
  
• The Windows 7 node on network A is only connected to the Ubuntu node
  

If they would exchange node lists, all three Windows 7 nodes would see eachother. But they don't. So they most likely don't exchange node lists. At least the network A Windows 7 should be able to connect to the network B Windows 7 nodes, because that direction has the very same public IP route.

Maybe you had added them tho tracker servers for a very short time? Even if you disable tracker server, that only prevents your nodes from renewing the tracker server data. It doesn't delete any information that already are there.

And back to the "read-only servers don't act as seeds" thing: I really think this isn't implemented and possible currently. And if you did see this in previouse versions, I guess that was kind of a bug. Not the current state.

Regards,

Stephan.

[chillicane]

I am positive that peers exchange peer lists with each other or at the very least, the server listed as 'use prededifend hosts' shares its peer list. Its working for me again now ive flushed the peer lists from sync.dat

All my read only endpoints are only set to use lan sync and predifined host - no dht, no tracker, no relay - and it definetly works. Most endpoints arent even on the same lan as others, they go out thru the internet and i use port forwarding to allow a bidirection connection.

I think the read only thing is simply a way of saying, if we change files in here dont push them out - just ignore, they should still seed for other peers. I have definetly watched them download off other read only peers when syncing.

My problem appears to have simply been that the cached peer list was dirty after the upgrade and there was no clean way to flush it without removing the folder shares.