Re: [Communicator-user] multiple connection help

[Samuel L. B. <sa...@mi...>]

   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