SLIP : Beyond Email.

SLIP is the Second Life Internet Protocol. It does not yet exist.

The idea is fairly simple (in concept, not in implementation) and yet extremely powerful. Like many features in LSL in involves two parts, a library call and an event handler.

The Library Method:
llSlip(string ID, string message)

ID requires some tricky work because it should be able to handle 2 different types of data:
- A psuedo address (gained by the event handler)
- An IP address

What this does is send a UDP packet to a person's computer containing (among other header info) the data in 'message'.
The psuedo address is there to protect privacy - there is no way to get someones IP from this system. However there needs to also be the option to send directly to a known IP.

The Event Handler
slip(string ID, string message)
This method is called whenever a specifically designed UDP packet is sent to a specific address, specific port of the SL servers. Part of the additional header information is the code necessary to get it to the right script in world. The string ID is a psuedo address that links to a real IP on the SL servers. It is used so that a responce packet can be sent without giving the real IP to the script / player.

There are many great things that can be done with this. Many. Too many to list. IT would basically allow players to create their own real world plugins for SL. Including using a a webcam linked to an attached script that controlled animations to adjust facial expressions etc. A player made RW -> SL communications tool (or a trillian plugin to do the same). LOTS OF STUFF!

Yay I'm late for work, have fun tearing it apart.

Plugins in hypermedia? Just dont tell Eolas!

Hey, I like it. Could allow for a lot of posibilities, however it could also be used in abusive ways. Fear denial of service Slip attacks. I think the fear of actually implementing the email receive functions which are documented would also cross over to here. But personally, I am all about getting both working.

I'm all for it if the potential abuses can be blocked. I would love to be able to do some plug ins for SL

I'm not being sarcastic, but what do you people see as the potential threats? I think there are a lot, and that I can't think of them all off the top of my head.

* TCP is slightly more sane, and an implementation that used a TCP setup would be equally welcome by myself. This might allow for some more control of the data before a connection is established? It is higher overhead, and while not used when both client and SL are controlled by the same people, it may be worth it for something like this.

* Delays. Only accept a message from any one source and only send to any 1 source every X time frame - 5 a second or so?

* A lot of backend work. Making sure that packets to scripts that don't exist get properly disposed of. Making sure that this doesn't give scripts any extra in world powers. Essentially making sure that ALL that happens is some data gets sent to an event handler, or data gets sent from an event handler.

This is probably a feature for SL 2.0, seeing as how the ability to create real world plugins for SL would very dramatically change the entire environment, and expand the capabilities.

Because of how slow scripts are, it would be possible (and in fact trivially easy) to run a DoS attack against a script listening for a SLIP message -- if you could figure out the ID it's listening for. For the same reason, a single script can't be used for an effective DoS attack.

The real threat is that a SLIP message would be used for a breakin attempt against someone's computer. For protecting against this, UDP is better than TCP, since UDP is connectionless, and almost all breakin attempts involve establishing a connection to the victim's computer.

OK, but can you use another acronym? SLIP is already taken in a network context as meaning Serial Line Internet Protocol

-Morse

Carnildo, I think a system that defines how often it will accept a message for a script, and thus drops all others, would prevent DoSing a script. A similar limit on Linden's end of limiting how many packets can be sent to a specific IP, independant of which script sends the packet, could prevent DoS attacks outside of SL. I know you dismissed them because of script speed, however you can have a LOT of scripts on a single object, and you can get a lot of objects all sending packets to a single address. It is preventable though I think.

Or an extreme prevention of DoS ... a response required system. With a script you can send 1 packet to a 'new' IP, after that you can only send a second packet to that IP after you have recieved one in return. Maybe add some fudge to account for dropped packets - can send 2 for each received or something. That requires a lot of overhead though and is probably not the best solution to the problem.

Morse, got any ideas? I like SLIP. All the good acronyms are taken anyways. Maybe Linden Internet Protocol (LIP) or Free Linden Internet Protocol (FLIP)? I would suggest Hippo Internet Protocol but I dunno about HIP.

I'm not really worried about it being used for attacks, was just saying it should be properly secured if its going to happen.

How about Hippo Internet Protocol Presently Operating (HIPPO). Hehe, or Linden Labs Asynchronos Message Broadcasting Accounting (LLAMBA)

Actualy, Linden Internet Protocol sounds good, could add a System and get LIPS, since its used for talking between SL and IP's it'd work on two levels

An alternate feature path: SLAPI. The Second Life Application Program Interface. Essentially it would allow similar functionality, however instead of dealing with packets and whatnot directly, your "plugin" would communicate with the SL client which could communicate with your scripts in game. It would allow more control and security. Also if combined with server side scripts (another feature I posted somewhere in that what it would take to make SL a game platform thread) it could be much more powerful.

Yummy yums.

Why not do both?

That way you could have objects talk to your computer and your computer talk to objects. Really the only difference would be though that with "SLIP" you could have a object send something to you without having a plug in have to deal with it.

Personaly though I'd prefer SLAPI cuse I think it'd be fun to write some plug ins for SL

Even for LIPS you should be able to communicate back to the SL servers. The difference becomes I think: should you be required to have SL running for that interaction?

I can see many security reasons for requiring communication to go through SL aka SLAPI.

I can see many use reasons (data storage and retrieval when not online) for wanting communication when SL client is not running, which would make LIPS more powerful.