You guys are trouble. Obviously I have to buy my way out of this by offering to procure a few rounds... Are you both at fitc? And who else will be there? I saw Lisa Larson and Rob Reinhardt's names...
While there are other ways to maintain shared state, I've found Remote Shared objects to be the best way to maintain shared state in an application. By that I mean things like who is in the room (one slot per user) or the position of players on a board (perhaps a shared object for each player in addition to the so with one slot per user) etc... In Muriel's post what caught my attention (delurked me?) was the idea that she might just be using the RSO to send messages by filling a slot and then clearing it. Muriel, is that what you meant?? If you are doing that, you may be able to move to using rso.send instead or redesign how the SOs are used. Anyway, in my experience updating an rso every .1 seconds is often not realistic. Usually the frame rate has to be dropped and some other method like dead reckoning used to smooth out and keep the action in a game close to a reasonable state. I'm a big fan of the update patern where the client makes an nc.call to the server and then the server broadcasts the update to all clients by setting a slot in an rso. But the problem with fast moving games is each nc.call is queued on the server and must be procesed sequentially by the single AS thread. (Unless you multithreaded instances in Red5?) So for some games direct - client side rso updates might be better... It all depends... Anyway, Muriel if you could describe the situation in a little more detail it might be helpful. Yours truly, -Brian, mostly lurking, Lesser John Grden wrote: > Me too, I was just about to say the exact 2 things Jake said! > > BRIAN - you lurker you ;) > > On 4/19/07, *Jake Hilton* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I knew it! .. I felt a lurker such as your self.. LOL :) > > But on topic.. I don't use shared objects much .. but use > nc.call's for a lot of my interaction. > > Jake > > > On 4/19/07, *Brian Lesser* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi Muriel, > I'm just a lurker here and am not using Red5 but was wondering > what you > mean by: "as the Shared Objects are emptied after a message > has been > received"? > Yours truly, > -Brian > > muriel wrote: > >>Hi all, >> >>we just had an interesting discussion with a Flash expert > about Shared >>Object communication. Until now, we have been using Red5 > Shared Objects >>for client-server communication in a multiplayer game setup. > As we have >>all kinds of communication (broadcast to room, some users, > single user), >>we have set up an architecture with two Shared Objects per > client (two >>distinguish input from output). We are now observing some > performance >>problems on the clients as well as the Red5 server (99 % CPU > usage with >>33 clients updating the Shared Objects every 0.1 seconds, btw > with 33 >>clients 66 Shared Objects have to be handled by the server). > On the >>server-side, however, we don't have any memory problems, as > the Shared >>Objects are emptied after a message has been received. Memory > is at >>around 4% and remains quite stable throughout the application. >> >>The Flash (Media Server) expert proposed to use an invoke of a >>client-side method rather than a Shared Object as this is more > efficient >>for the client to handle. Do you think the server performance > issues >>could be due to the Shared Objects? And does it make sense to > change >>from Shared Object communication to RMI? >> >>Is there anyone who has experienced similar problems? >> >>Thanks for helping, >>Muriel >> >> >> >>_______________________________________________ >>Red5 mailing list >> [email protected] <mailto:[email protected]> >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> > > > -- > ______________________________________________________________________ > Brian Lesser > Assistant Director, Application Development and Integration > Computing and Communications Services > Ryerson University > 350 Victoria St. > Toronto, Ontario Phone: (416) 979-5000 ext. 6835 > M5B 2K3 Fax: (416) 979-5220 > Office: POD B-66-C E-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > (Enter through LIB-B99) Web: > http://www.ryerson.ca/~blesser <http://www.ryerson.ca/%7Eblesser> > ______________________________________________________________________ > > > > _______________________________________________ > Red5 mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/red5_osflash.org > <http://osflash.org/mailman/listinfo/red5_osflash.org> > > > > _______________________________________________ > Red5 mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > -- > [ JPG ] > >------------------------------------------------------------------------ > >_______________________________________________ >Red5 mailing list >[email protected] >http://osflash.org/mailman/listinfo/red5_osflash.org > > -- ______________________________________________________________________ Brian Lesser Assistant Director, Application Development and Integration Computing and Communications Services Ryerson University 350 Victoria St. Toronto, Ontario Phone: (416) 979-5000 ext. 6835 M5B 2K3 Fax: (416) 979-5220 Office: POD?? E-mail: [EMAIL PROTECTED] (Enter through LB99) Web: http://www.ryerson.ca/~blesser ______________________________________________________________________ _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
