Persistent server with GUI interactive functions ?

[Frank]

On Thu, 03 Apr 2003 11:09:29 +0200, Thomas Guettler
<pan-newsreader at thomas-guettler.de> wrote:

>On Thu, 03 Apr 2003 10:29:28 +0200, Frank wrote:
>
>> I need to write a GUI app that will serve as a peer to peer
>> client/server.  At the highest level it would be similar to a chat
>> client, which has a server component (waiting for any incoming
>> connections) as well as the client part (initiating a connection,
>> executing user commands).
>
>How are your client and server connected? 

The client and server are the same program (peer to peer).  Think of
any of the chat or video-conference apps around.  They usually CAN
connect to a central server to post their existence, but do not need
to.  Any client-server can connect to or accept connections from any
other client-server, as long as the address is known
>
>Can both create tcp sockets to each other? 
>You can't do this if a client is behind a masquarding (NAT)
>router. If you can use TCP/IP, I think Pyro is the best choice. I have
>not used it yet.
>Can the client make a tcp connection to the server? Some networks only
>allow http through a proxy. If some clients are behind a http proxy
>I would recommend xml-rpc.
> 
Each instance can start a connection and accept one from someone else,
using TCP.  I'm not worried about the NAT/firewall issue, I have that
under control.
>
>> Each of those function appears to involve entering an "endless loop" as
>> the last logical step to initiate processing (i.e. "mainloop()" for the
>> user interface and "serve_forever()" for the server).  I haven't yet
>> grasped the logical structure that will allow me to have two
>> non-returning calls and maintain control of the program.
>
>I would do it with threads. Maybe there it is possible to do it without 
>threads, too.
>
>In the subject you used the word "Persistent". I would use pickles for
>development. If you have too much data you can switch to ZODB later.
>
I meant "Persistent" in the sense of the server function:  it will
wait for a connection, do its thing, and then wait for the next
connection, not terminating until a user command is given.
> thomas