Still the same I'm afraid.
No network id displayed on the Moto G although I did get one from the cheap tablet.
Pinging 127.0.0.1 in a terminal emulator seems to work on the Moto G in any case.

I couldn't get adb to work - still reporting offline even with sudo! Maybe that would give us a clue as to what is going on?




On Wed, Dec 17, 2014 at 2:53 AM, Chris McCormick <chris@mccormick.cx> wrote:
Hi Gavin,

> My Moto G doesn't report a unique network id for some reason.

This is a fairly critical bug. The protocol won't behave well if a node
is lacking a uid. After looking at the uid object I think this could
happen if a device lacks the "loopback" interface 127.0.0.1 - so I've
changed the code so that a) it tries to gather network entropy by
connecting to 0.0.0.0 instead and b) it falls back to just using the
startup entropy if the network entropy fails.

I have pushed this code - do you mind testing again?

On 16/12/14 06:48, Gavin wrote:
> Quick update - I got rid of the 255.255.255.255 broadcast option and it
> seemed to make things much better, though still not perfect.
>
> Is the patch meant to choose Android network broadcasting
> (192.168.43.255) if available and if not then fall back to lan blanket
> broadcasting? I'm not sure but for me, both spigots were open and I
> think the network was getting congested.

The protocol is designed so that it can send on as many interfaces as
possible redundantly. This is so in future I can drop in other
transports like mesh networking and whatever packets make it through
first will be the ones that get used. Because each message gets a unique
ID the protocol can easily drop redundant messages.

Because of the way that message retries work (based on a simple checksum
of the state hash) if something is broken with the uids it will probably
result in a lot of traffic as the nodes try and get the broken node up
to date.

I probably need to include a retry counter where if a node is
continuously behaving badly it gets ignored by the other nodes
eventually, say after 100 retries. I'll add that to the TODO.

> Now it works much better but there is still some lag and I am getting
> alot of
> $2 : argument out of range messages - not sure where they originate from.

That's not good. Those were plaguing me and I could not find the source,
but they went away when I got all the other bugs ironed out. Can you let
me know if the latest from GitHub exhibits the same symptoms?

https://github.com/chr15m/SyncJams

Thanks for testing!

Cheers,

Chris.

--
http://mccormick.cx/



--
Gavin
www.digitalfunfair.co.uk