ephrem@oakhill.UUCP (Ephrem Chemaly) (02/24/90)
I am starting a new project where an X client is reading a port and collecting data from another machine. I would like the data collected by this 'collector client' to be sent to other X clients to be analyzed, displayed, saved, etc. I am using the XSendEvent(..., XClientMessageEvent) to send the data to all clients that registered their interest with the 'collector client'. This allows me to send 20 bytes of data at a time. It seems to me that I am replicating a small portion of X since when a client has an interest in the data it has to register itself, the kind of messages it is interested in receiving from the collector, it also has to unregister itself when it no longer needs the data (usually before it dies). Is there a better way to send data between clients or am I on the right track. Thanks in advance. Ephrem A. Chemaly oakhill!soleil!ephrem@cs.utexas.edu (512)891-2760 MOTOROLA Inc. 6501 W. William Cannon Dr. MS OE28 Austin, TX 78735 U.S.A.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/24/90)
Is there a better way to send data between clients or am I on the
right track.
Yes, don't use X for this purpose, use a real IPC mechanism (e.g. RPC).
X is not a general-purpose communications mechanism, and shouldn't be
abused as one. (Remember, you asked for "better", not "more practical
and equally portable". :-)karlton@fudge.sgi.com (Phil Karlton) (02/24/90)
In article <3010@soleil.oakhill.UUCP> ephrem@oakhill.UUCP (Ephrem Chemaly) writes: >I would like the data >collected by this 'collector client' to be sent to other X clients >to be analyzed, displayed, saved, etc. I am using the >XSendEvent(..., XClientMessageEvent) to send the data to all clients >that registered their interest with the 'collector client'. This allows >me to send 20 bytes of data at a time. There is another way to tackle this particular communication paradigm. Have the "collecting" client create a window and publish its ID by hanging a property on the root windo under some private property name, say "_CHEMALY_PROPERTIES". Have the collecting client hang properties of an appropriate name and type on that published window ID. As displayers come and go, have them select for PropertyNotify on that window. This way the X server takes care of the registration and shut down for you. Additionally, you can transfer more than 20 bytes at a time. Be careful of mixing data of different sizes (8, 16 or 32 bits) within a single property because this will byte you if you ever run the collector and displayer on machines with different byte orderings. If you have more than one set of collectors and displayers then you will have to have a more complicated initial handshake for determinating the window to be used. PK -- Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039 Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039
madd@world.std.com (jim frost) (02/25/90)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: >don't use X for this purpose, use a real IPC mechanism (e.g. RPC). What an interesting idea -- using RPC for IPC. Talk about torturing a mechanism.... jim frost saber software jimf@saber.com
xxai121@ut-emx.UUCP (Tim Jones) (08/18/90)
I am trying to develop a way for about ten X Windows programs to communicate
with each other through the X Window interclient communication mechanism.
There are basically two modes of communication: a program having data that
other programs can come and get (passive send / active receive), or a program
desiring data whenever other programs send it (passive receive / active send).
No assumptions are being made about the operating system the programs are
running under, or that they are even on the same machine. It is assumed that
they are using the same X server. We are using X version 11.3 and the Motif
toolkit. Generally our messages are short (1-20 bytes).
Right now we have a system using the Intrinsics' selection mechanism that
allows two different programs to communicate in either mode. The passive send
/ active receive is implemented with standard selections. The passive receive
/ active send is also implemented with selections, where the selection is an
Atom that represents a program's identity (we have established a set of known
program identity atoms). By asking for this selection, and indicating a desiredconversion type, another program indicates that data is available for the
identified program wanting the data (the kind of data being represented by the
conversion type). Although it uses a nonstandard interpretation of the
conversion type, this mechanism provides the desired communication modes between
two unique programs. It also handles the case of multiple programs wanting the
same data (they are notified individually and individually come get the data).
The current system has some limitations we need to overcome. First, it does
not handle the case of multiple versions of the same program running at the
same time. We are using a known selection atom to represent each program and
it is not possible for more than one program (or window) to own the same
selection atom. One current idea is to implement a system of undetermined
selection atoms representing each program; however this would involve each
program notifying all other programs whenever it starts or ends, and what its
identifying atom is. This seems to have the benefit of allowing multiple
versions of the programs to communicate with each other in both modes, but the
drawback of each program having to keep track of all the other programs' atoms.
A second limitation is not handling the case where more than one program has
the same kind of data for other programs to read. That is, it cannot handle
the case of two copies of program A and B both trying to do a passive send /
active receive of the same data. This is characteristic of the selection
mechanism, which only allows one program to own a particular selection. The
"undetermined atom" idea does not solve this problem.
Basically we are wanting a system that handles both modes of communication and
the cases involved with multiple versions of multiple programs communicating
with each other through the same X server.
Does anyone out there with experience in this kind of thing have some
suggestions? Right now we are just using selections. Has anyone implemented
a similar system using client message events, property notify events, the Motif
clipboard, or some other mechanism? Does anyone have some ideas?
I would appreciate any responses,
Tim Jones
Note: my computer will be shut down from 8/27 to 9/4. Any mail sent during that
time should be sent via a friend at chris@nth.comkeith@EXPO.LCS.MIT.EDU (Keith Packard) (08/18/90)
> There are basically two modes of communication: a program having data that > other programs can come and get (passive send / active receive), or a program > desiring data whenever other programs send it (passive receive / active send). > Right now we have a system using the Intrinsics' selection mechanism that > allows two different programs to communicate in either mode. The passive send > / active receive is implemented with standard selections. The passive receive > / active send is also implemented with selections, where the selection is an > Atom that represents a program's identity (we have established a set of known > program identity atoms). By asking for this selection, and indicating a desiredconversion type, another program indicates that data is available for the > identified program wanting the data (the kind of data being represented by the > conversion type). For the second type of transfer, I think you want to use the special selection target INSERT_SELECTION. This causes the selection owner to request the specified selection contents. It was originally designed to allow the two clients to exchange data in both directions at one time, but it doesn't matter if you only use the reverse direction. Keith Packard MIT X Consortium
koe@kivax.UUCP (Diana Koehler) (10/24/90)
I am just working with the different mechanisms of interclient communication. What method should I use - to exchange data between clients ? (Properties or XSendEvent, with type ClientMessage) - to notify a client without sending data (in sense of semaphores) Thanks Diana ------------------------------------------------------------------------ Diana Koehler Tel.: +49 7721 867034 Mannesmann Kienzle GmbH Abt. 011.2 e-mail: koe@kivax.UUCP Postfach 1640 ..!mcsun!unido!kivax!koe D-7730 VS-Villingen ..!uunet!unido!kivax!koe
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (10/25/90)
In article <880@kivax.UUCP>, koe@kivax.UUCP (Diana Koehler) writes: |> I am just working with the different mechanisms of |> interclient communication. |> What method should I use |> - to exchange data between clients ? |> (Properties or XSendEvent, with type ClientMessage) |> - to notify a client without sending data (in sense of semaphores) |> |> |> Thanks |> |> |> Diana |> |> ------------------------------------------------------------------------ |> |> Diana Koehler Tel.: +49 7721 867034 |> Mannesmann Kienzle GmbH |> Abt. 011.2 e-mail: koe@kivax.UUCP |> Postfach 1640 ..!mcsun!unido!kivax!koe |> D-7730 VS-Villingen ..!uunet!unido!kivax!koe If you have large amounts of data, you should probably not use X for your communication (fairly slow). Instead, have one application create a socket and send the port # (via X) to the client that you wish to communicate with. Then use simple reads and writes to communicate. Obviously not as portable as X but sometimes the speed can demand it. Client notification is handled nicely with XSendEvent(ClientMessage). -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
erc@pai.UUCP (Eric Johnson) (10/26/90)
In article <880@kivax.UUCP>, koe@kivax.UUCP (Diana Koehler) writes: > I am just working with the different mechanisms of > interclient communication. What method should I use > - to exchange data between clients ? > (Properties or XSendEvent, with type ClientMessage) > - to notify a client without sending data (in sense of semaphores) I'm assuming you mean you want to only send short messages between your clients. The X Window System is not intended to be a generic inter-process communication (IPC) system. If you want to send large amounts of data, you'll probably have a better time with sockets, streams, shared memory or some other IPC technique. A common technique for X Window applications to exchange short messages is to: 1) Append your application's window ID to a "known" property on the root window. By known property I mean a property that all your applications agree to beforehand. The window ID is necessary for using XSendEvent(). Window IDs also will change each time you run your applications, so writing the window ID to a property solves the tough problem of finding the window IDs of the applications you want to communicate with. 2) Use XSendEvent() to send short messages to the applications that have registered an interest in those messages (that is, those applications that have appended their window IDs to the property on the root window). The ClientMessage event type allows you to send 20 bytes of arbitrary data with each message. Another cute thing is to send KeyPress/KeyRelease events to an application and pretned the user actually typed the keys. (This is useful for application testing, too.) There's a whole chapter on sending events in Advanced X Window Applications Programming (a book I'm responsible for). Send me e-mail if you would like more information on this. > Thanks > Diana Koehler Tel.: +49 7721 867034 > Mannesmann Kienzle GmbH > Abt. 011.2 e-mail: koe@kivax.UUCP > Postfach 1640 ..!mcsun!unido!kivax!koe > D-7730 VS-Villingen ..!uunet!unido!kivax!koe Hope this helps, -Eric -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA
sivan@bpa_su10.Sbi.Com (Sivan Mahadevan) (10/31/90)
In article <1506@pai.UUCP>, erc@pai.UUCP (Eric Johnson) writes: > > I'm assuming you mean you want to only send short messages > between your clients. The X Window System is not intended to > be a generic inter-process communication (IPC) system. If you want to > send large amounts of data, you'll probably have a better time > with sockets, streams, shared memory or some other > IPC technique. > We do a lot of interclient communication here and find the need to use different techniques (sockets, shared memory, signals, ClientMessage) depending on the context. A tip for those who might want to make Xlib calls in signal handlers: we built a more "reentrant" Xlib by setting the LockDisplay() and UnlockDisplay() macros in Xlib to block and unblock, respectively, relevant signals (e.g., SIGUSR1). -- Sivan Mahadevan Salomon Brothers Inc Bond Portfolio Analysis Analytical Applications Group One New York Plaza 44th Floor 212-747-5418 New York NY 10004 sivan@bpa_su10.sbi.com uunet!sbi.com!bpa_su10!sivan