Matt Florell wrote:
On 5/18/07, Dean Collins <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:asterisk-users-
> [EMAIL PROTECTED] On Behalf Of Matt Florell
> Sent: Friday, 18 May 2007 4:22 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] asterisk manager interface stability
> > >
> >
> > Neat. So the clients use a polling model? Individual clients then
> > query only for events that are interesting?
> >
> > Warm Regards,
> >
> > Lee
>
> Yes, the clients only connect to the MySQL database and can query the
> events as they need to for their display.
>
> MATT---
>
>
>
> >
> > _______________________________________________
???? Wouldn't that make it highly inefficient? Is there no two way
dialog or am I missing something?
It is inefficient, but it is non-blocking which the AMI is not. having
a separate listen and separate send processes removes the problems
with AMI locking up on high volume Asterisk systems.
Basically if I have 100 end user clients that needed real time
interaction with astproxy are you saying that each client would need to
poll once per second (eg 100 polls per second) in order to see if
something happened that second that was relevant to them?)
Not a problem for MySQL, that's what it does best. The astguiclient
application can do 20+ queries per second per client depending on the
application. I currently have one company with over 200 client
applications(AJAX) sending 3000-4000 queries per second to the MySQL
server, and it handles it just fine. On the client side, the load is
not very high either, even on a PIII 700MHz machine.
Nice. And using a DB to cache events no doubt simplifies the mechanics
of the application making it easier to develop and maintain.
--
Warm Regards,
Lee
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
