Tom Sawyer wrote:
> 
> On Friday 10 January 2003 10:07 am, Martin Hart wrote:
> > That's fine if each client is also a server, but I had hoped to do this
> > without each client process (there may be many) having to be a socket
> > server.
> >
> > Am I misunderstanding what you mean?
> 
> well, seems to me, if you want to send notifications to the client, then 
> the client will have to be sitting there "listening", so in a sense, 
> there's no escaping it, whether your doing it yourself or having a library 
> do it for you.
> 
> i'm not 100% clear on what your trying to achieve. so i'm just throwing 
> out some basic thoughts and i'm by no means an expert on network coding.

While I don't consider myself an expert, I work for a company that has
to deal with these sorts of issues, so I'll take a shot at this.

In order to get notifications from the server to the client, the client
has three basic options:

1. Open a server socket, which I guess you don't want to (or can't) do.

2. Poll the server at periodic intervals to collect any pending
notifications.  This tends to waste bandwith, consume server resources
to queue up unclaimed notifications, and delay notification delivery.

3. Make a connection to the server and hold it open indefinitely.  The
best option, if you can do it.

Note that you can do #3 with HTTP, by stretching the definition of
HTTP.  There's a JavaWorld article on "Pushlets", in which the server
returns "infinite content" from an HTTP POST or GET.

   http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html

Of course, this technique has lots of problems, especially when proxies
lie between client and server.  Many proxies make reasonable assumptions
about HTTP traffic that this technique violates; others are just plain
broken.  

-- 
Frank Mitchell (frankm / bayarea.net)

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html