[Red5] RMI or Shared Objects
Jake Hilton
red5 at jakehilton.com
Thu Apr 19 23:21:52 EDT 2007
Brian,
I wasn't trying to make you feel guilty... but I guess you did that all on
your own... :)
I wish I was at fitc but I can usually only do one conference a year and so
that'll be max07 in Chicago.
You'll have to procure a few rounds for the lucky few who got to go.
Interesting idea with mixing nc.call and rso's.
Thanks,
Jake
On 4/19/07, Brian Lesser <blesser at ryerson.ca> wrote:
>
> 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* < red5 at jakehilton.com
> > <mailto:red5 at jakehilton.com>> 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* <blesser at ryerson.ca
> > <mailto:blesser at ryerson.ca>> 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
> >> Red5 at osflash.org <mailto:Red5 at osflash.org>
> >> 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: blesser at ryerson.ca
> > <mailto:blesser at ryerson.ca>
> > (Enter through LIB-B99) Web:
> > http://www.ryerson.ca/~blesser <http://www.ryerson.ca/%7Eblesser
> >
> >
> ______________________________________________________________________
> >
> >
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org <mailto:Red5 at osflash.org>
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> > <http://osflash.org/mailman/listinfo/red5_osflash.org>
> >
> >
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org <mailto:Red5 at osflash.org>
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
> >
> >
> > --
> > [ JPG ]
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Red5 mailing list
> >Red5 at osflash.org
> >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: blesser at ryerson.ca
> (Enter through LB99) Web: http://www.ryerson.ca/~blesser
> ______________________________________________________________________
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070419/c55c9b3f/attachment.htm
More information about the Red5
mailing list