Digging a bit deeper, it seems as if the realtime object is not working on my Moto G
I'll attach a demo patch which should display the realtime output when hitting the trigger. Works on my laptop - no effect on the Moto G. Any ideas? On Wed, Dec 17, 2014 at 2:53 AM, Chris McCormick <[email protected]> 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
droidparty_main.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
