|
From: Samuel L. B. <sa...@mi...> - 2002-01-31 22:16:42
|
Greetings.
I'm far from a Communicator expert, so I'm helping someone can point me
in the right direction.
We've built an "Interactive Book" which is "architected" as follows: On
the PC/Mac client, we use Java to display the layout of the book, and
perform animation. This client connects to a Linux server which houses
servers to perform text-to-speech synthesis, speech recognition, speech
alignment, and so on.
The server applications are running in Galaxy Communicator, as you might
expect. In order to allow client connections, I wrote a Galaxy
"bridging" server to accept connections from a client machine, and send
data (text or audio) back and forth to the other servers in Galaxy. So
the Java client connects to Galaxy via a socket-based connection to the
"bridging" server.
The system works, but now it's time to consider multiple clients. I'm
trying to understand the Galaxy documentation with respect to threads,
but it seems a little sparse, at least for me, and in addition, I don't
even know if what I want to do is possible.
The way I envision handling multiple clients is to have my bridging
server act like a standard Unix daemon: It accepts a connection from a
client, then forks a child who handles that client and goes back to
listening for more connections. But that would mean I would have
multiple bridging processes, all of whom are Galaxy Communicator
servers. Possible? If not, is there another way this can be accomplished.
There are several ways to do this, and they don't necessarily require
forks or threads. Unfortunately, none of them are completely
straightforward. Here are your options:
(1) Turn your Java display into a Communicator-compliant server. This
is easier than it sounds; really, all you need to do is link
against libGalaxy.jar and create a thread running the
GalaxyCommunicator main server. The new Open Source Toolkit (just
released) has a couple examples of Java UIs which are also
Communicator-compliant servers. Each server connects to the Hub as
a client, and as long as they're each associated with different
sessions, you should be able to keep the interactions
separate. The toy travel demo example in the GalaxyCommunicator
distribution works like this. We can also provide you with some
guidance, if need be.
(2) I'm not sure how your bridge server works, but if it's in C, you
must have done something like using Gal_AddTask() to poll the
connection to the Java display. If the listener socket is already
on the bridge server side, you're already halfway there, because
you're already polling the listener socket. All you really need to
do is to set up tasks for each connection you accept, and use
something like GalIO_ClientConnect() to establish a client
connection to the Hub. Tie the two ends together by storing the
data in the appropriate client_data slots, and bingo, you're
done.
Those are the two simplest approaches. In order to make my best
recommendation, I'd need to know more about what you're doing now. And
don't feel discouraged: handling multiple UIs and multiple
participants is probably the hardest programming task the
infrastructure supports.
Cheers,
Sam
|