I may just have to stick with nc.call and eat the penalty. There is no counterpart to nc.call that does NOT expect a reply message?
Paul deCoursey wrote: > How about this, use nc.call to notify users when another user had > entered/exited it's range and have the client register/deregister SOs. > I'm not sure that will save much, setting up a SO might be an expensive > call. Or perhaps the shared object for each user has a list of users in > range that the server just updates.... or would that entire list be sent > each time a single item in it is updated? > > Naicu Octavian wrote: > >>> Suppose I only want to send position data to players that are within a >>> >> certain range. For example, anyone within 100 "meters". >> >> Your mileage will vary. If you have 1000 connected users and in each >> 100m radius there are only 10 users then nc.call can be a good >> decision! but in such a case you can also have a SO for each 100mx100m >> sqare radius,etc... .Depends on what you are trying to do! >> >> On 28/08/07, * Mike* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Good point, Octavian. >> Suppose I only want to send position data to players that are within a >> certain range. >> >> For example, anyone within 100 "meters". >> >> SharedObjects don't really give me that luxury, do they? >> I may be forced to use nc.call? >> Or, is there another method? >> >> Is there a version of nc.call that does NOT require a return message? >> >> Naicu Octavian wrote: >> > >I agree with everything said here, but i must add something to >> defend >> > poor nc.call's :) >> > >> > Another thing is that with nc.call calls for the server to the >> clients >> > you can target specific clients. A ns.send sends the info to all >> > clients subscribed to that SO. This is a more general issue but >> good >> > to have in mind when one is developing a private messages >> feature for >> > example! :) >> > >> > -- >> > Naicu Octavian, >> > Project Manager for AVChat >> > http://www.avchat.net <http://www.avchat.net> >> > >> > On 28/08/07, *Storm* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> >> wrote: >> > >> > I agree with everything said here, but i must add something to >> > defend poor nc.call's :) >> > >> > SOs may have a bad behaviour in some extreme cases such as >> > updating right before disconnecting and such. I've had to >> change >> > some functionality from SOs to nc.calls due to this, those "few >> > bytes" of the callbacks are pretty useful to ensure that the >> > update has been really recieved. Therefor everything has its >> > place, even in a one-to-all update scenario. >> > >> > Cheers >> > >> > >> > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> > >> > Dominick Accattato schrieb: >> > [...] >> > > 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. >> > >> > using so.send or SO syncs even saves you a few bytes >> bandwidth >> > as for >> > nc.call, the client sends back the result of the method >> call >> > to the >> > server (or the server back to the client) which isn't >> done for >> > SO events. >> > Well, just a few bytes ;) but if you have lots of calls... >> > >> > Joachim >> > >> > >> > _______________________________________________ >> > Red5 mailing list >> > [email protected] <mailto:[email protected]> <mailto: >> [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]> >> <mailto:[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 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > > > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
