We were drawn because of the notion that zeromq contained a version of openpgm which ran on android. Are you saying it runs on android but does not support wifi ? We would be talking about the udp encapsulated pgm of course. In my experiments with trying a vanilla java.net multicast the low transfer rate was a major problem, and I was hopping for something better, with a lower level program which in addition to doing FEC and NAK could set a higher transfer rate. Am I barking up the wrong tree ?
> From: [email protected] > Date: Wed, 2 Jan 2013 20:40:54 +0100 > To: [email protected] > Subject: Re: [zeromq-dev] use zeromq for pgm audio broadcast to android > devices ? > > I'm pretty sure (but Stephen can confirm) that WiFi switches do not > offer IGMP snooping, which PGM requires. > > Over WiFi your choices are either TCP, for up to 8-10 devices, or UDP > multicast (probably with recovery over TCP) thereafter. I've not seen > an open source UDP+0MQ mass transfer protocol; it would be > interesting. > > You need to beware with any multicast over UDP since the bitrate the > switch will use will be extremely low, even if all devices are close > by. > > The quality of work you can do over WiFi depends seriously on the WiFi > switch quality, interference, and physical spread of the network. > > -Pieter > > On Wed, Jan 2, 2013 at 7:27 PM, Dan Reardon <[email protected]> wrote: > > We are new to ZeroMQ and want to use it to distribute media over wifi to > > phones and other devices, potentially a very large number. > > > > > > (a) Has anyone used PGM over WIFI to devices yet? Anyone tried it with > > hundreds or thousands of phones? (b) How well does it (or should it) work? > > (c) If the wifi / electrical environment is dirty, will zeroMQ's queuing > > mechanisms get in my way? (e) What other issues should I expect to have to > > work around? (f) Tricks and tips? > > > > > > We do not need or want > > > > "guaranteed delivery", as this is a real time broadcast, missing > > > > audio segments should be substituted with silence when the cannot > > > > be obtained in time to keep up with the audio stream. Will we run into > > problems BECAUSE of message queuing we don’t want or is there a way to get > > in under that layer and avoid queues overflowing, etc.? > > > > > > Is there any chance that anyone would want to implement Uflood, Ucast or any > > other protocol specifically designed for wifi? How do we get this onto the > > “wish list” or product road map? > > > > > > We may be in a position to provide a testbed environment for large-scale > > wifi testing if someone else wants to develop the code! Who should we be > > talking to? Anyone interested in being the lead archtect or developer if we > > can support testing? > > > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
