LiquidGalaxy / liquid-galaxy

Automatically exported from code.google.com/p/liquid-galaxy
Apache License 2.0
61 stars 20 forks source link

View Sync packets via UDP multicast #9

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
G'day - another enhancement request.

Being able to send viewsync updates to remote (or local) systems via multicast 
is something that would be useful.

Use case examples:

1. linking multiple Liquid Galaxy setups together which are on different 
locations on different networks. 

2. sending out views to multiple remote GE clients, say distributing around a 
campus network or distributed classroom environment.

We use multicast for collaboration over AccessGrid (www.accessgrid.org) it 
relies on multicast to deliver video/audio & other application data to sites 
involved in realtime collaboration activity.

Multicast addresses are in the address range 224.0.0.0 - 239.255.255.255
The packets normally have an user defined time-to-live (ttl) ie. how many hops 
they can travel as a maximum.

I don't think this would take much work to add to the existing ViewSync send 
and receive code.

Possible additional drivers.ini settings, and examples...

ViewSync/muticast_address = 239.255.1.1 (this would be used on the master and 
slaves)
ViewSync/multicast_ttl = 127 (needed just on the master)
ViewSync/port = 21567 (used just the same way)

Or you could use the existing ViewSync/hostname and add ViewSync/ttl.

If GoogleEarth was multicast-aware it would be an app that would have an 
immediate application as a collaborative tool in AccessGrid facilities.

A workaround is to have a service acting as a UDP-to-multicast relayer/bridge. 
The View Master sends the UDP packets to that listener and it would be 
responsible for re-sending the packet using a configured multicast address. At 
the other end the reverse would be needed. Actually I'm assuming the ViewSync 
packets are sent via UDP I haven't checked.

Cheers, Andrew.

IT Research Support / ITS / University of Western Sydney

Original issue reported on code.google.com by alfski on 13 Oct 2010 at 7:51

GoogleCodeExporter commented 9 years ago
Neat, thanks for the info.  I keep coming back to the idea that somebody should 
write a simple viewsync multiplexer that could handle all sorts of interesting 
use cases: switching between multiple masters, turning individual slaves on and 
off, tunneling messages over SSH/SSL, etc.  Seems like something that could be 
done in a few pages of python or perl.

Original comment by jh...@google.com on 13 Oct 2010 at 7:14

GoogleCodeExporter commented 9 years ago
Multicast should be an easy win. The current "send to broadcast address" is 
roughly the same as using a multicast IP address with a ttl=1 (so it doesn't 
leave the local subnet). The clients just need to be modified to listen to the 
multicast packets as well as directed/broadcast.

A viewsync multiplexer (or controller) could do lot's of things...
- toggle individual layers on particular slaves.
- send out different lat/long/yaw/pitch/roll for each slave. For example, 
perhaps you want to show the eiffel tower on every screen OR a different 
national monument on every screen and then let people pick which one they can 
visit.

Original comment by alfski on 14 Oct 2010 at 2:45

GoogleCodeExporter commented 9 years ago
Suggest change this to an "enhancement" request?
We have a viable work-around using a viewsync relayer.

Original comment by alfski on 27 Jun 2011 at 1:41

GoogleCodeExporter commented 9 years ago
as we have workaround - changed type to enhancement, lowered priority.

Original comment by alfski on 3 Jul 2011 at 3:57

GoogleCodeExporter commented 9 years ago
summary line tweak

Original comment by alfski on 3 Jul 2011 at 6:45