At 08:48 PM 7/6/00 +0100, Jason Chapman wrote:

>
>> A more radical approach is to allow an dormant connection (pick a
>> metric) to break the TCP connection to the server, reestablishing
>> itself as required.

>As long as it can happily keep transactions alive during this virtual
>connection.
>

Absolutely. Any mechanism should be transparent.

>>This scales better at the cost of a little
>> more work, and if the server can manage the connection pool, everybody
>> can stay connected until a limit is approached. The hard part is
>> a server heuristic to decide when a client has croaked. A periodic
>> keep-alive message -- a little wasteful of resources -- could do the
>> trick, but there is always the danger that a clogged network could
>> result in the loss of an important connection.

>Doesn't IB already does this with a 60 - 120 second ping of the client?
>This appears to be dynamically timed at the moment & could be further
>enhanced by a configurable but hidden variable.
>

Arggg! Not another insidious installation parameter! When are
you guys going to stop trying to cram XML down my throat!

It would be nice to be able to control both the interval and required
response time. There also needs to be some way to specify connectionless
attachments. Maybe I'm going to have to resign myself to a config
file. Shall me make it XML? Object Oriented? Expert System?
Neural Net?

>
>>Another problem
>> is event delivery. All in all, however, this is probably the best
>> solution.
>Could each client have a dedicated message pending client socket?
>It would need this socket for the ping as well.
>

The current mechanism uses a separate connected socket for event
delivery. This would obviously need to be changed. I can't
think of any reason that a single client accept socket could
be shared between the "ping" mechanism and event delivery. Maybe
not what you want for high volume events, but current TCPs are
almost certainly optimized for fast, cheap connections.

Jim Starkey