Wow. Thanks, Dominick! This is the kind of info I needed. Dominick Accattato wrote: > Mike: > > Good question, but SharedObject's are the way to go. It seems you are > aware of efficient SharedObject design. If your data is chatty, you > should design your slots to hold only the information necessary for > the functionality you desire. In terms of x, y coordinates, you > should have a slot that holds only coordinate information. An > inefficient SharedObject design would hold an entire User object which > has account information, coordinate information, etc.. With this > design, anytime you update the x or y coordinate, the entire User > Object would be sent to all clients. > > That said, your probably still wondering about whether SharedObject > sync is the most efficient way. I believe the answer is yes. Here is > my reason why: > RTMP is a protocol which basically consists of a header and amf data, > therefore an "invoke" is represented by a hex number and so is a > "sync". With that in mind, your only efficiency concerns are between > the Red5 framework and your application code. > > * So, a sharedObject is sent to the framework and the framework > handles sending it back to all the clients. > * An invoke would be sent to the framework, which would then be > sent to your application code, which would then be sent back to > the framework and then down to the client. > > Now, if you were talking about using the SharedObject.send method, you > may not need to bubble up to your application code, but your still > being sent to all the clients. That being said, you should just use > the sharedObjects sync functionality anyway. > > Last, I would like to say that I think all these functions probably > behave almost identical in efficiency. I don't think you will find > that much difference in performance. The only thing that can really > be in-efficient is a poorly designed sharedObject. > > Hope this helps a little! > > On 8/27/07, *Mike* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Thanks for all of the great replies. > However... > > My question is not really about the logic. > My question is about efficiency. > > Is it actually more efficient to use Shared Objects in this case. > For example, I know Shared Objects can be inefficient if they are > larger because the entire object is sent when any property of the > object is updated. > > Any input on this? > -Mike > > Lenny Sorey wrote: >> I would have to agree with Storm on this issue of Shared Objects. >> >> I also would use Shared Objects. >> >> Lenny >> >> >> On 8/27/07, *Storm* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> > wrote: >> >> I'd use shared objects for that if you ask me. >> >> Cheers >> >> On 8/25/07, *Mike* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Is it more efficient to use SharedObjects for everything, >> or to use >> inokes on clients? >> >> For example, let's say I have a game with 20 users connected. >> Each user is updating their character's position in the game. >> >> Is SharedObject the way to go, or should I loop through >> every client and >> perform an invoke when updates are made? >> >> >> _______________________________________________ >> Red5 mailing list >> [email protected] <mailto:[email protected]> >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> >> >> >> -- >> ------------------------------------------------------------------- >> If a man speaks in a forest and his wife is not there, is he >> still wrong? >> _______________________________________________ >> Red5 mailing list >> [email protected] <mailto:[email protected]> >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Red5 mailing list >> [email protected] <mailto:[email protected]> >> http://osflash.org/mailman/listinfo/red5_osflash.org >> > > > _______________________________________________ > Red5 mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > -- > Dominick Accattato, CTO > Infrared5 Inc. > www.newviewnetworks.com <http://www.newviewnetworks.com> > ------------------------------------------------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org >
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
