[comp.windows.x] Multicasted X-Windows??

garyf@mehlville.ncsa.uiuc.edu (Gary Faulkner) (12/13/89)

We have heard a rumor that someone has made mods to X to allow a single
X-client to multicast its output to multiple servers (and allow interaction
from all of the users sitting at the display attached to those servers) 
concurrently.  Does anyone konw about this?  It would solve several problems
we are working on here which involve multiple, remote users interacting with 
the same "program" at the same time.  Was this possibly incorporated into
X11R4?

Any information would be greatly appreciated!!


Gary Faulkner
National Center for Supercomputing Applications - University of Illinois
Internet: garyf@mehlville.ncsa.uiuc.edu
Disclaimer:  I've only stated my opinion, not anyone elses.

holtz@zurich.csmil.umich.edu (Brian Holtz) (12/13/89)

In article <1989Dec13.131654.16066@ux1.cso.uiuc.edu>
garyf@mehlville.ncsa.uiuc.edu (Gary Faulkner) writes:

>We have heard a rumor that someone has made mods to X to allow a single
>X-client to multicast its output to multiple servers (and allow interaction
>from all of the users sitting at the display attached to those servers) 
>concurrently.

HP is working on something called SharedX, in which output is multicast
to a set of X-servers, and input is switchable among those servers
on the basis of a floor-passing protocol.  You can't do better than
floor-passing (i.e., you can't get true concurrency) without modifying
the client to deal with consistency maintenance.

neideck@nestvx.dec.com (Burkhard Neidecker-Lutz) (12/19/89)

Digital's Project NESTOR has developed something called shX (no pun on
the HP sharedX intended, I didn't know about that and would love to hear
more about it).

We modified the R3 Xlib to provide the dynamic addition and removal of
displays to a running application. Like the HP thing we use a floor passing
protocol ("passing the chalk...") to have some degree of orderliness with
the application. We can deal quite good with different depth displays and
color/mono differences, but there is a lot more work to be done.

We gave our code to some people in the consortium and outside and we intend
to release it through the ordinary channels on expo (and gatekeeper) some
time after R4. First of all we want to base the code on the R4 library instead
of on R3, second we have to fix numerous bugs, omissions and one or two
memory leaks.

The code currently runs on both VAXes and DECstations running Ultrix and
we successfully build sharable versions of most applications in the core
MIT distribution, InterViews 2.5, some DECwindows sample applications and
bozos such as colorwheel.

	Burkhard Neidecker-Lutz, Digital CEC Karlsruhe, Project NESTOR
	neidecker@kampus.enet.dec.com