Hi Jonathan,

Thanks for the explanations.

What I was already thinking of is kind of delaying/stacking the
userJoin/left events. On the APE_JSF side, there is this option of
stacking them and sending the data at once.
Doing the same thing on the server side and collecting join/left for,
say, 15 seconds and "bulk send" them, could also be an option. I just
don't know how...

I am just not sure if this can be done/implemented on the server side,
intercepting the events, collecting and "manually" sending them out. I
assume, the userJon/left events are not to be overwritten by JS but
are coded in C. Am I correct?

Since we are talkting about a "many-to-many" chat application here, we
need to know who is online and who is not - I don't see a good
approach for this using non-interactive pipes - or am I mislead here?

Appreciate your help!

Thanks

Peter




On 18 Okt., 16:49, Johnathan Leppert <[email protected]>
wrote:
> Peter,
>
> Although you could get that many users on an interactive channel, as you
> mentioned client/server performance would be poor. It's possible, and the
> client side framework actually defers initialization of object, but in my
> experience the JSON responses tend to get large, slowing down other events
> on the channel (since events are processed synchronously). Bottom line is
> you still need to have a proper and sanely designed system in order to get
> good client/server performance. It's very possible to have 1000's of users
> if the event system is well designed.
>
> If you're going to have interactive channels it would be wise to set a
> maximum number of users for each channel to reduce the amount of events.
> This can be easily accommodated for in server side javascript.
>
> You can have many users on a single, non-interactive channel by prefixing
> the channel name with an asterisk, so users will not receive join/left
> events and can't directly publish to the channel.
>
> Johnathan
>
>
>
> On Mon, Oct 18, 2010 at 10:27 AM, KaroDidi <[email protected]> wrote:
>
> > Really? And what about my web browser?
>
> > Assuming we "only" have 5000 concurrent users on one channel.
> > A new user joins the channel.
> > He will receive 5001 userjoin events in an instance, and the server
> > has to send 5000 userjoins to all other users.
> > Another user leaves, another user joins... this creates a vast amount
> > of userjoin/userleft events that need to be handled - also by the
> > client.
>
> > I was wondering if this really works out?
>
> > Any experience?
>
> > Peter
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "APE Project" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]<ape-project%2bunsubscr...@googlegr 
> > oups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/ape-project?hl=en
> > ---
> > APE Project (Ajax Push Engine)
> > Official website :http://www.ape-project.org/
> > Git Hub :http://github.com/APE-Project/

-- 
You received this message because you are subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/

Reply via email to