[ace-users] =?gb2312?B?tPC4tDogW2FjZS11c2Vyc10gtPC4tDogIFF1ZXN0aW9uIG9mIFJlYWN0b3I=?= =?gb2312?B?cycgaW1wbGVtZW50YXRpb24=?=

Mai Haohui ricetons at gmail.com
Sat Aug 4 22:08:52 CDT 2007


Yes. I can call application event handler in handle_timeout(), but I cannot
know whether there are any pending events for the handler (i.e., network
I/O), so it seems to be impossible to decide to close the connection or not.

Even checking the connection state periodically does not help, since the
reactor always prefers timing events and there're no ways to know whether
there're pending events or not.

I think making a patch seems to be the best way of the problem so far :-).

Mai

----- Original Message-----


On Aug 4, 2007, at 11:48 AM, Mai Haohui wrote:

> Thanks for your reply.
>
> C++NPv2 states that the order of event handler dispatching is based on
> empirical results and application should be rely on the order.  
> However, many
> servers tend to disconnect with the clients if they are idle in order 
> to release the resources for performance concerns, for example, the 
> default configuration of ACE limits applications can only open 
> FD_SETSIZE (typically
> 1024 on Linux) handles simultaneously, which means the Reactor can 
> handle
> 1024 TCP connections at best, and disconnecting idle connections would 
> benefit the throughput.
>
> A common practice is that to disconnect the connection in 
> handle_timeout(), which cause the problem.
>
> It is okay for the client that the server refuses connections from the 
> clients, but it might be a bit of frustrating for the clients if they 
> sent the request and disconnected without any responses :-(. In those 
> cases, timeout events just indicates the clients are idle which does 
> not need to be precise, so it seems that the current order in 
> dispatch_i() would be unfit for some application.

Why don't you just track this state in your application?  Rather than
handle_timeout() closing the sockets directly, let handle_timeout() call
something in your app's event handler that says "hey, things timed out so
you can close" but, ultimately, let the event handler itself decide whether
it WILL close based on the state of the connection at that time.

I think you're going to have a tough time getting an implementation of
something like this generic enough for inclusion into ACE because it relies
on the state of the connection *at the application level*.

Of course, I could be completely misunderstanding what you're trying to do.

---
Chris Cleeland, Principal Software Engineer http://www.theaceorb.com AND
http://www.ociweb.com





More information about the Ace-users mailing list