Re: [sldev] Gesture client code

[Dzonatas Sol]

UDP is a bit more low level and asynchronous than TCP. Buffer overruns would immediately mean drop packets, so a slow process wouldn't have to worry about it being the reason the rest of the system is slow due, like, TCP where blocked I/O could lead to other processes being blocked until the one catches up.. UDP via IPv6 would have some further advantages even for local use merely because of the how the address can be used as a subset of a UUID. That's a whole thread of discussion that has been touched on in SLDev before, so I won't go into specifics about that. However, I think those transport specifics aren't a critical issue in order to achieve the basic goal, which any local system stream will do and that includes a UDP provider. There is already a UDP Reliable Message provider in Snowglobe. Once the network stream is initialized by UDP between the two processes, then a reliable message would not be needed, and it can use plain asynchronous fire-and-forget UDP. With any local system stream allowed, then there are choices to use UDP, TCP, pipes, stdin/stdout, files, or any custom stream provider to connect to the gesture tracker. The transport specifics, which are already implemented, are not something that needs to be re-implemented in the main class of the gesture tracker or its base classes. Tateru Nino wrote: In this case, you'll find that the functional difference between the two is negligible. If you were going off of the metal to another machine, that would be a bit different. For local use? UDP doesn't have an edge in this particular circumstance. Philip Rosedale wrote: Looks like DBus is TCP based - that still seems unneeded, I think we should use UDP, what think? Jan Ciger wrote: XML is definitely an overkill and certainly shouldn't be used for anything that has aspirations to be lightweight. Just use DBus - that is pretty standard and portable lightweight RPC mechanism and it is in the viewer already - it is used for passing slurls to the viewer from Linux browser. That would also allow easy scripting of the viewer in the future. Regards, Jan _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges