Recommendation: GSI CHUF (v1)
Translation function for strings into chat channels for CLEP and other messages.
The Global Scripting Institute (GSI) is an informal organization of Second Life® users that design and test standards for efficient, flexible, and readable scripts in Second Life. "Second Life®" and "Second Life Grid™" are trademarks of Linden Research, Inc., d/b/a Linden Lab. The Global Scripting Institute and its catalog are not affiliated with or sponsored by Linden Research.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
The Channel Hash Utility Function (CHUF) generates an number (integer) channel based on a string domain in Lua and Linden Scripting Language (LSL). This allows CLEP and other messages to have automatic channel separation by domain, which reduces the number of events triggered when a large collection of objects is broadcasting messages to each other on a common hard-coded channel integer.
The CHUF MUST be implemented as bit32.bor(ll.Hash(domain), 0xC0000000) in Lua, or (llHash(domain) | 0xC0000000) in LSL.
This accomplishes the following:
domain string, which is returned as a 32-bit signed integer number in both Lua and LSL, of which two bits are omitted by the bitwise operation, resulting in a 30-bit channel space.| Placeholder | Type | Description |
|---|---|---|
domain |
string | MUST be a string of any value. This value can be treated as an arbitrary "string channel". A pre-shared string, the prim's UUID, another prim's UUID, or some combination of the three, is RECOMMENDED if a CLEP domain is not used. |
The Channel Hash Utility Function is not designed to be secure or private. The SDBM algorithm is not cryptographically safe and collisions are extremely rare, but possible given the resulting 30-bit channel space.
Why are channels hashed? Isn't it better to have a pre-shared channel?
Per the Second Life Wiki, the Second Life server processes every chat message by first checking that it matches the channel of any open listens in the region, then performs some additional checks (self-chat, distance, other filters). If - and only if - those checks pass, a listen event is added to the script's event queue.
The CHUF enforces channel separation using hashing to take advantage of the performance gains offered by this check. Traditionally, LSL scripts use a pre-shared channel integer for a certain product. If a shared channel is used, any broadcasts that need to be done via llRegionSay, llSay, llShout, or llWhisper are sent to all scripts listening to that channel.
Advanced networks of scripts tend to use multiple channels to offset this. However, sharing multiple integers as channel numbers is complex, and the integers don't themselves have any substantial intrinsic meaning.
The CHUF does something similar, except that the channel numbers are deterministically pseudo-random by use of a hash function. That way, instead of randomly coming up with a channel number, CHUF channels are effectively defined as strings and the actual integer channel used internally is deterministic but irrelevant.
As a result, using the CHUF subtly enforces channel separation and reduces script impact overall by reducing unnecessary listen events.
This recommendation was authored by Nelson Jenkins on behalf of GSI.