Talk:LSL Protocol/Ganymedia OpenMAIP v1.0 Specification

Alpha status as this draft has, I miss the specification on how IP Address assignment and service discovery works. Also, specifics as to ad-hoc configuration and region handover (in case of avatar attchments) seems to be missing. Question: If chat is the predominantly used transport, does this imply llRegionSay()? Question: Is there information on message overhead available? Question: How scalable is that? Imagine you have a region with 30 avatars, each with 5 attached prims implementing a service or looking for services...what would be approximately the basic chat messages/minute load, service related traffic excluded? (Pure infrastructure).

An alternative solution could be to use a (linden labs provided) or third party infrastructure, serving 2 purposes: 1. Service discovery (I was using a google app engine self-written service discovery in some of my tests in that area). Distributed service discovery like bonjour has its charms, but so has a lag-free SL experience. For inspiration, check back the multicast messages sent by dns-sd, for example. 2. Relaying and region handover management. (The attached scripts detect region change, adjust their address with the infrastructure. Communication uses 1 level of indirection to address communications partners.) Transport protocol negotiation and optimization could be managed by such an infrastructure as well. E.g. to allow to fall back to lsl chat transport if both communications partners happen to be within chat range/same region).