[PD] PdDroidParty latency, syncing etc.

[Gavin]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141217/e7a9aadd/attachment-0001.html>