Grid-Wide Comm System, Radio, Message, Walkie Talkie

[Kehf Nelson]

Been fiddling with this idea for a while, I understand the basics but curious as to the best practices for this type of system.

At this point I'm not asking to help with the actual scripting, that will come later. For now I'm picking the forums collective brains as to the best way to handle the flow of events.

--
Looking to create an open source SL Wide method of "Chatting" via huds. Think, Rescue-Beacon, GPS locator (Press a button, Avatar as it these Grid Coordinates) , Very Limited (64 Character) llTextBox()  means of communication.

Minimize Resources, Avoid Spam through a system of authorized senders, perhaps multiple "channels", and have some means of scalability.

I have access to an external KVP system so depending on the SL structure, can have all the messages reside there, or keep a key of an in-game server up to date after rolling restarts.

How much of the finished system is in game or external depends on issues of scalability, lag, http request limits, etc

 

The Flow of this sort of thing is where things get a bit sticky for me.  Let's assume the following scenario of a Rescue-beacon.  You have many possible victims "V" and a smaller population of Rescuers "R"    

Either V or Rs will get a little radio hud thing. 

V huds have 1 button, "Help me ON" or "Help me Off"  
R huds have a button that opens up a llTextBox() dialog and  lets them respond to the V radio that's sending the helpme

When a V presses Help me, the R's are alerted to that, presented with the ability to send a short message via an llTextbox back to the Help Requesting V's hud device.
 

Assumptions: 
-V can only send one helpme  Ping every 5 minutes
-R can only send one llTextBox every 1 minute
-S will get a rolling restart and its UUID will change at least once a week
-We don't know how many R's and V's there are at any one time
-HelpMe Messages contain the sender's Key, Location, TimeStamp, and Receiving URL for messages back
 

 

Idea 1: Using KVP primarily

R huds user a timer, every 10 seconds they query the KVP server for the "latest/last" message, if no change do nothing
V requests a helpMe, their hud, WRITES an alert request to KVP (Receiving HTTP URL, to communicate back, location, timestamp, etc)
R 's hud beeps when the checked message != to the previous message
R chooses to send a message back via the inbound HTTP URL that corresponds to that V prompt
Problems: Not very feature rich, multiple messages, or events could overwrite each other, no server side processing/cleanup

Idea 2: Uses an in game "server"

S starts up, writes to external KVP it's in game UUID/URL.
R and V get the UUID/LSL Query URL of the server "S" via the external KVP server, each time they change regions or something
R on a timer queries S for the last "batch" of messages
V requests a helpme by sending a message to S with (location, timestamp, etc)
V starts a timer to query S for updates to it's helpme
S Packages that request into a message
R receives that message on it's next query
R responds to that query via an llTextBox back to S
V receives that response from S
Would get a single point of authority for all the users.
Probably run into a limit of HTTP requests, I assume this wouldn't scale very well, too many inbound HTTP posts to S?
More ability to manage a list of messages, cleanup.

 

Idea 3: Bit of a hybrid, might scale better if there are... 50 or so Rs
S starts up and writes it's UUID/URL
S on a timer queries KVP and grabs the last X number of messages, sorts, prunes, organizes via LSL (Cleans up the old messages and is the authority for message order)
S Writes to KVP the CurrentMessageDocument
R and V query KVP on startup or region change for S's UUID/URL
V goes to Idle
R on a timer Queries KVP for CurrentMessageDocument
Time passes
V Writes a HelpMe to KVP (Location, Time, Receiving HTTP URL to communicate back)
S  catches that HelpMe Record on the timer
S Amends to KVP the CurrentMessageDocument, deletes the HelpMe KVP Record
R on a timer sees a change to CurrentMessageDocument
R responds via an llTextbox to V on the Receiving HTTP URL submitted in the helpme message

Idea 4: Rolling message pruning
S starts up, queries KVP for all messages on a Regex'd key
S Prunes old records maybe leaving only those messages that are < 30 Minutes old
S starts a timer to Prune every 60 seconds.
V Starts up, goes idle
R starts up a timer and Queries KVP for the latest messages
R Sorts messages llOwnerSay'ing "new ones"
V sends a helpMe
R on a timer Sees a new message
R can Respond back to the helpme Record on V's URL
Uses the S for External DB management only.
Scalable?

So, what are your ideas on how to "skin this cat" 
Is there a better way to flow the information that would make communication scalable for all involved?

 

 

 

[Quistess Alpha]

So, to turn down complexity, I'd make V and R mostly identical, just have one 'shared radio system' which can be listened to or not.

When 'listening' is turned on (either a R goes on duty, or a V needs help)

• the HUD requests a URL (via llRequestURL) and forwards it to the server. The server adds the URL to a list, forwards the URL to all other URLs on its list, and responds with an updated list of all URLs it has stored.
• the HUD updates its internal list of all other URLs.

similarly for changed region, turning listening off etc. the server and all HUDs in the system attempt to keep a shared list of every listening URL.

when a HUD wants to send a message, it just HTTPRequests every URL stored in its list.

The main limitations are A) the total memory of the server, and B) total memory of the HUD scripts and C) the maximum message lengths. As long as care is taken to set HTTP_BODY_MAXLENGTH in requesting scripts, there shouldn't be much practical limit on message sizes. assuming each URL is about 200 bytes, you start to run into problems at about 125~150 simultaneous users, as the scripts need to store both the old list and an updated one at the same time. if you 'cheat' and make assumptions about the format of URLs, you can drastically increase that at the expense of the system possibly breaking in the future. Different 'channels' could could fairly easily be set up for different shared lists, the laziest way would be to just have a different server for each 'channel'.

If a request to a server's previous URL returns 404, use llEmail to ask the server for its new URL, which it should re-request in its changed event on CHANGED_REGION_START. as long as the server object is never moved to a new region (actually maybe even if it is?) its UUID and by extension its email address remain constant, even through region restarts.

[animats]

There are several such systems in SL.

These actually work. You can call people who have Gentek phones in world from them. Calls are text messages, not voice.

They were intended for contemporary roleplay sims. At one time, Gentek had a staffed call center with operators. If you called 911 on an Gentek phone, you were connected to an emergency operator who could forward your call to the appropriate in-world emergency service. They'd help to move roleplay forward.

The lights are off, the consoles are unattended.

You can still buy Gentek phones. They're all very 1990s. All landline, no cellular. There's a phone store at NTBI. There are large Gentek central office buildings and microwave relay towers in world. There's even a phone book. But don't expect anyone to answer.

There are at least two systems with two-way radios - GridNet and GridTalkie. GridNet seems to be popular for cop/firefighter/military type roleplay, while GridTalkie is popular with marine and aviation roleplay grouns.

 

 

[Kehf Nelson]

Yup I looked at those systems but near as I can tell they are not opensource. Part of the fun for me is learning how to build and do it. 

 

[Kehf Nelson]

I agree about the complexity. Simple SendOK permission bit in the script.  BodyLength should be ok, have a library I use for http that takes care of that.

 

I appreciate the feed back, will be posting the working tests as I fiddle with the project.