Re: Thoughts on 2-way RPC

I think a 'real' connection makes more sense than letting a developer 
manage a polling session.

Having done TCP/IP for 20+ yr now, and a lot of it driver/wire level I 
think some issues are being missed.

1) How well will the application scale when 100's (1000's?) of users are 
polling?
If the server is forking or reusing threads for each session, a lot of 
high processing would be needed. If a network level keepalive doesn't 
require anywhere near as much processing.

TCP/IP added SO_KEEPALIVE for a reason, but it also has a cost, but much 
smaller than application level in the stack. A keepalive can be managed 
without the application ever being given a time slice (depending on OS 
and IP stack).

Depending on the language used and the OS possibly only 1000's per 
process or 10,000's per IP can be supported concurrently. But when 
weighting processor use vs total sockets, the processor overhead 
normally causes a limit first when polling is used.

2) In polling a 'most recently connected' counter would be needed along 
with a thread/process to clean up 'dead' connections. This is yet more 
complexity people aren't including in the discussion.

3) I would have to check the restart code for SSL, but I can't imagine 
that restarting a SSL connection is even close in cost to just using the 
same already open connection.

4) Some applications have either larger back-end resources per user, a 
process per user, and/or need to know if a user is gone, a persistent 
connection makes a lot more sense.

It has been said before that 'something new' might need to be done to 
have a persistent connection supported 'at a cost', but the cost of 
doing polling and the supporting logic can be much larger. Maybe one of 
the other projects XATP, etc. has support we can reuse. Not every 
application will use all the features, but some will, and unless they 
are willing to build a lot of extra 'stuff' like I just had to they 
won't make the choice to use XWT.

-Jeff

Charles Goodwin wrote:

>On Wed, 2004-01-28 at 10:19, Adam Megacz wrote:
>  
>
>>So, the choice we're stuck with is simple protocol or simple
>>server-side implementation.
>>    
>>
>
>I think it would be easiest to go with our own server-side standard of
>polling and returning every few seconds.  That way we can pool multiple
>polling requests into the same thread on both the client and server.
>
>We just have to document it 'tis all.
>  
>