[Red5devs] SharedObject design question

[Dominick Accattato]

Your problem is that your storing all the data in just one slot.
SharedObject design has the idea of slots.  A SharedObject can have many
slots.  This notion of slots allows you to separate what gets synchronized
among clients.  So in your case you shouldn't be storing 1 list in the
SharedObject.  Instead, you should have 150 slots.  one for each user.  Hope
this helps.

On Tue, Sep 16, 2008 at 7:21 AM, Valentin Manthei <
contact at valentin-manthei.de> wrote:

> Hi out there,
>
> I currently run a webcam chat community with advanced features.
>
> Users broadcasting their webcams have a list of viewers to control the
> access to their webcam, kick a viewer from it etc.
>
> This list is stored in just one SharedObject with the following layout:
> [user1] => [viewer1, viewer2, viewer3]
> [user2] => [viewer1, viewer4]
> ...
>
> This works fine, but in fact with every update of the viewerlist every
> broadcasting user gets information about the changes (and in most cases
> this information is not relevant for the target, because it is
> subscribed by every user).
> Would it be better to create a SharedObject for every broadcaster?
> That'd be up to 150 SOs at a time.
>
> Is Red5 able to handle a large amount of SOs? Will that probably be more
> efficient than using one huge HashMap for everything? Is an increase of
> performance to expect?
>
> It is a lot ofwork to implement the SharedObjects this way, so I wanted
> to ask first.
>
> Thanks for your help,
> Valentin
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>



-- 
Dominick Accattato, CTO
Infrared5 Inc.
www.infrared5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20080916/4198a7de/attachment.html