<div dir="ltr">Still the same I'm afraid.<div>No network id displayed on the Moto G although I did get one from the cheap tablet.</div><div>Pinging 127.0.0.1 in a terminal emulator seems to work on the Moto G in any case.</div><div><br></div><div>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?</div><div><br></div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 2:53 AM, Chris McCormick <span dir="ltr"><<a href="mailto:chris@mccormick.cx" target="_blank">chris@mccormick.cx</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gavin,<br>
<br>
> My Moto G doesn't report a unique network id for some reason.<br>
<br>
This is a fairly critical bug. The protocol won't behave well if a node<br>
is lacking a uid. After looking at the uid object I think this could<br>
happen if a device lacks the "loopback" interface 127.0.0.1 - so I've<br>
changed the code so that a) it tries to gather network entropy by<br>
connecting to 0.0.0.0 instead and b) it falls back to just using the<br>
startup entropy if the network entropy fails.<br>
<br>
I have pushed this code - do you mind testing again?<br>
<br>
On 16/12/14 06:48, Gavin wrote:<br>
> Quick update - I got rid of the 255.255.255.255 broadcast option and it<br>
> seemed to make things much better, though still not perfect.<br>
><br>
> Is the patch meant to choose Android network broadcasting<br>
> (192.168.43.255) if available and if not then fall back to lan blanket<br>
> broadcasting? I'm not sure but for me, both spigots were open and I<br>
> think the network was getting congested.<br>
<br>
The protocol is designed so that it can send on as many interfaces as<br>
possible redundantly. This is so in future I can drop in other<br>
transports like mesh networking and whatever packets make it through<br>
first will be the ones that get used. Because each message gets a unique<br>
ID the protocol can easily drop redundant messages.<br>
<br>
Because of the way that message retries work (based on a simple checksum<br>
of the state hash) if something is broken with the uids it will probably<br>
result in a lot of traffic as the nodes try and get the broken node up<br>
to date.<br>
<br>
I probably need to include a retry counter where if a node is<br>
continuously behaving badly it gets ignored by the other nodes<br>
eventually, say after 100 retries. I'll add that to the TODO.<br>
<br>
> Now it works much better but there is still some lag and I am getting<br>
> alot of<br>
> $2 : argument out of range messages - not sure where they originate from.<br>
<br>
That's not good. Those were plaguing me and I could not find the source,<br>
but they went away when I got all the other bugs ironed out. Can you let<br>
me know if the latest from GitHub exhibits the same symptoms?<br>
<br>
<a href="https://github.com/chr15m/SyncJams" target="_blank">https://github.com/chr15m/SyncJams</a><br>
<br>
Thanks for testing!<br>
<br>
Cheers,<br>
<br>
Chris.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="http://mccormick.cx/" target="_blank">http://mccormick.cx/</a><br>
<br>
</font></span></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Gavin<br><a href="http://www.digitalfunfair.co.uk">www.digitalfunfair.co.uk</a><br></div>
</div>