Mass communication relay system.

Jamie, IM has a delay of 2 seconds, and objects can't receive IMs.

Rye, those are good reasons

From what I can tell, there are a few protocols out there, but they are proprietary. What's needed, and I think we already agree, is a standard, open platform that anyone can build upon.

Your thoughts on ISPs are interesting. I imagine something like that would evolve naturally. For one, implementing this system will require hard work, so whomever does can likely sell the baseline hardware for the network to recoup costs. Standard, modular scripts that can "plugin" to other scripts could also be available, preferrably free, allowing developers an "API" for communcation which would free them to focus on their project better.

Using the network itself could be free, but I don't know if I see it happening. You'll have landowners who have this network on their land, taking up sim cycles. They will want compensation. Either landowners will allow the network on their land out of kindness, or some equitable means of royalties to landownders would be needed. They would essentially become like the telcos did with the advent of modems and dsl. Seems metered bandwidth would be needed, or at least flat rate pricing. Perhaps a one time charge per object created to use the network? Hard to say, but any barriers to entry must be minimized if such a system were to be widely adopted. And then of course, comes the day when LL adds it as a feature.

... just thought of possibly the killer app. for this thing. You could create service type scripts that can be called remotely (like Web Services). So you could have like a giant warehouse of objects somewhere that 3rd party vendors can access via calls to your GetWarehouseInventory service or something like that; pricing can be updated in 1 place etc.. Or some complex calculation script... The actual services can vary but hopefully you get the picture.

Foolish, without having put any Deep Thought into it I'll ask: have you looked into anything like Gnutella or some other decentralized P2P protocol? Given that you're interested in tracking constantly moving nodes, the situation seems a bit like that experienced in a file-sharing network, where you're splitting bandwidth between discovery and genuine messages. Just a thought.

Also -- for long distance communication beyond the range of llShout(), how about using physical objects? Ie, encode your message on a 'bullet' and shoot it at a receiver far, far away? Or -- pulls and pushes on long cables composed of 30m long physical rods?

Jess

I myself have just completed smll scale tests of my own relay network. This plan was a hold over since beta, and well I just started playing again.

I don't know about other implementations, but the first one mentioned seemed somewhat flawed. I think the greatest problem was that they each had a big message buffer, and kept copies of old messages for ghosted replies. I don't like this style at all cause it leads to each object possibly recieving the same message many time. Also many suggestions of increasing the memory, or the amount of scripts also seems off to me. You must understand that the object can't keep up with the information, so if you add more memory it just takes longer for the buffer to fill then cease working.

Additionally alot of the later suggestions for using it for banks and communications doesn't seem to be required. The Email functionality already could be used to cover these in a much simpler platform. have a server with an address. email a request to it, email back a reply.

However, for my needs I want something alot faster, and yes it is a mental excercise of implementation. The network which is still in mid developement phase is loosely based around Frame Relay and other programming practises. I think I have come up with a very simple and efficient way for relay networking which I will incorporate into virtually all my future projects as well as allowing my group to utilize it as a backbone for their projects.

However, this design doesn't quite match one of your requirements that an item such as a vehicle needs to be able to be in communication as it's moving around the sims. I may incorporate it in a later version of the protocol I have written.

If you are interested in my implementation please feel free to contact me, I do like idea sharing even though I may not be inclined to give away all my secrets The next thing I'm building is a real-time map to map out all avatars within a given territory.

Thanks,
Xyber

I just stumbled across this thread from last year...

So you're all saying that I should't have written a generic layer2/3 routing engine (largely based on my knowledge of real-life neworking) for a emulate-real-life-as-much-as-possible?

A brief description of the project can be found here: http://www.the-infinite.org/blog/articles/2006/06/15/geeking-out-101

In essence, each object in a chain auto-discovers neighboring objects using llSensorRepeat(), and builds it's layer2 (equivalent-ish of an arp) table based on that.

And as the system passes messages, each object builds a routing table containing [destkey, nexthopkey] tuples.

Then there's the BroadcastRequest() and SendRequest() functions which, well - either broadcast a message to all neighboring objects (sans the object the request came from), or send a message straight to a neighbor (Generally used as SendRequest(RouteLookup(destkey), msg);


- d.

No, we were merely saying that there might be a more efficient way to accomplish a task. I've actually been thinking about this myself-- maybe someday I'll get around to writing a suite of generic network scripts. Congratulations on your success with the power network.

Thanks for digging this back up. I had seen this refrenced in another thread, but never really looked through it. Building a layer2/3 system would be awesome. I've been thinking about setting up a system like this on Kula (where I live) just　to relay arround chat and maby some status indicators.
I think if anyone is serious about developing an open SL-IP protocol, that we should from a group and actually do something Theory is good and all, but one man/woman/implementation does not a stardard make.
--Jesse

Keknehv, Jesse,

I won't mind sharing a generic version of the layer2 discovery/layer3 routing stuff (with the approriate *Request() functions) that I wrote - it's pretty straight-forward once you understand it - and uses some interesting tricks to not have to hardcode channel numbers, etc... (I love autodiscovery ).

Maybe later this week while I'm sitting at home recovering from surgery, I'll throw something preliminary together...


- d.

The system I use parces the message using the pipe symbol

And then it does a search of the path for it's number

The address field is curently unused and would be used for routers which would listen on two chanels to direct the direction of flow. The routers would also strip the path as each path is local.

The message goes like this
"path" pipe To Address pipe data

,||message
,1,||message
,2,1,||message

The script does not store anything.

As an optomization you could start the string with ,| and then do a string search for ",n," where n is your number. This would allow you to check the path without all the parcing lists, but this would be more complex and more error prone.

//Released into the public domain by grumble Loudon
    listen(integer channel, string name, key id, string message)
    {        
	//Route|address|protocol|data

        list mList = llParseStringKeepNulls(message,["|"],[]); 
      
        string route = llList2String( mList,0); //route path
        list RouteList = [];
        if (llStringLength(route) > 0)
        {
            RouteList  = llParseString2List(route,[","],[]); //we can drop nulls here
        };
        string MyName = llGetObjectDesc();
        list MyNameList;
        MyNameList += MyName;
                
        if (llListFindList(RouteList, MyNameList) == -1){   // Returns -1 if not found

            string Msg =  MyName + "," + message;   //add me to the path
           
            llShout(m_Channel,Msg);

        }; //route path
    } // listen

nm

Tee hee! I was working on something like this earlier today. I was working on shouting messages around, relaying them through a chain of objects to communicate messages from objects covering over 800m in range to a central object that needed to receive all the data.

Then I realized "warp pos" has obsoleted the need for all this shouting and relaying. Each object can simply warp to the central object, whisper its message, and warp back home in a fraction of a second. Made things a heck of a lot easier...

There are probably cases where that's not a good solution, but it worked for my purposes.

!

brilliant!

0.0 You are right. The only problem is Sim crossings (which there is a fix to, but it's LONG).
No matter the underlying Layer1/"Physical" method, you still need a routing protocol and a message format.

I used warppos for a scanner system in similar manner, but there's also something very appealing in idea of 'physical' relay stations and such... the exact option to use would probably depend on what system you try to emulate ^^;

Heh. Designing systems and software is something I love, so I'm intregued at the possibility of a SL IP network.

Contact me in-world.

I already have a sim-wide wireless "routing" network - it has the same problems described earlier, however...

But I'm designing an improvement to it that creates self-optimizing routers - by computing TTLs it can perform rudimentary stateless packet routing. I'd love to get with someone who can focus on tuning those algorithms and fully implementing them (right now it's designed as sort of a client-server interface, with the assumption that all messages are either going to or coming from a central server)