LSL Protocol/rfedip

Ratany fine Engineerings Device Interface Protocol (rfedip)

The Ratany fine Engineering Device Interface Protocol (short: rfedip) is an extensible protocol for the detection of compliant devices and for the handling of the communication between such devices.

The protocol defines how devices can be detected and rules for how the devices can communicate. It does not define the very content of such communications, with the exception of a few so-called control messages.

The protocol has been created because there doesn´t seem to be any sort of standard to detect devices. Devices can be leashing posts, furniture, collars, cuffs and chastity belts as well as any other gadget the design of which involves interoperability or some sort of communication with other devices.

Using sensors to scan for devices has turned out to be an insufficient alternative. The sensor range is inevitably limited, and particular prims --- which may be the actual points of an object to tie a leash to --- of objects cannot be detected with a sensor.

Using existing protocols like the lockmeister protocol also turned out not to be feasible. A device using the lockmeister protocol only becomes active from an agent sitting on the device or touching the device, and the device does itself not listen for queries to identify itself.

At the time of this writing, open collar items seem to employ some sort of protocol and maybe even some sort of API. However, these are not documented, and development appears to be in progress such that significant changes might be implemented.

Other protocols may exist that are vendor-specific. Insofar their designs have not been disclosed, they are unsuited to achieve compatibility and interoperability of devices made by different creators. A device that lacks compatibility with other devices may have no more than a very limited use for the user of the device, especially when the functionality of the device genuinely requires that the device works with others.

The Ratany fine Engineering Device Interface Protocol is intended to encourage and to help with the creation of devices that are compatible with others.

The availability of a useful protocol does not mean that creators of devices will be inclined to use it. Please consider this article as a draft with the intention to create a useful protocol which hopefully might be used by many creators --- and as a request for comments. Please feel free to use the discussion page of this article to add your suggestions and ideas, or to contact me directly.

Editing this Article

This article is written in my favourite editor. When I update the article on the wiki, I edit the whole article, delete everything and paste the new version in. That´s simply the easiest and most efficient way for me.

Unfortunately, this means that your modifications may be lost when I update the article and don´t see them.

Please use the "discussion" page of this article to post contributions or to suggest changes so they can be added to the article.

Requirements brought upon a protocol

The protocol should be:

• available

• extensible

• independent of the medium which is used to transmit protocol messages

• reliable

• easy to implement/use

• compatible with previous versions of the protocol when new versions are created

Specification

In General

The rfedip protcol uses strings of characters that can be transfered as messages of a type which can be sent by functions like llMessageLinked(), llRegionSayTo(), llRegionSay(), llShout(), llSay(), llWhisper() as well as in the body of an email or via the use of the HTTP protocol.

An rfedip message is a string which is divided into fields by the use of a special character as separator. The fields of a message are defined as follows, and they appear in the message in the order they are listed here:

• sender-UUID: The UUID of the sending device.

• recipient-UUID: The UUID of the device the message is directed to.

• protocol version: A string that specifies the version of the protocol.

• payload: The payload of the protocol. The payload is generally assumed to consist of a token. The token may be followed by a parameter. Multiple tokens and parameters may be sent in a single message. However, a single message should not contain multiple tokens. Multiple messages should be used to avoid the creation of messages that contain multiple tokens.

All devices compliant with the rfedip protocol must have available documentation about all the tokens and, if applicable, the parameters used with the tokens the device supports. The documentation must include the tokens and parameters the device understands, as well as the tokens and parameters it might use itself to communicate with other rfedip-compliant devices.

This is to ensure that creators and users of rfedip-compliant devices can refer to the documentation of devices created by others and make the devices they are creating compatible with devices created by others, if they so choose.

A device for which such documentation is not freely available cannot be considered as compliant or compatible with the rfedip protocol.

Definitions

The rfedip protocol itself defines:

• a string specifying the protocol version: "RFEDIP-1.0"

• that future versions of the protocol must maintain compatibility with previous versions of the protocol

• a suggestion as to what may be considered as "sufficient version": "RFEDIP" (What is considered as "sufficient version" for a particular device is up to the creator of that device.)

• the special character that must be used to seperate a string of characters into fields in order to form a protocol message: "|"

• a default communications channel, when applicable: -20131224

• supporting email and http as transport media for protocol messages is optional; supporting the default communications channel is mandatory

• a token that designates a request for a device to identify itself: "identify"

• a token that designates a protocol message a device identifies itself with: "identity"

• a token that designates a protocol message signalling that a communication (sequence) has ended, mandatorily followed by the channel in question: "msg_end!"

• a token that designates a protocol message requesting that a particular channel, if applicable, be used for further communication, mandatorily followed by the channel which is to be used as a parameter: "openchan"

• that a particular channel which was opened can be closed when the device that requested opening this channel sends the protocol message that signals that a communication (sequence) has ended

• that a particular channel which was opened on request of a device can unconditionally be closed one hour after the last communication has occurred on that channel

• that identification requests must always be answered (consequently, the default channel must never be closed, even not when a device signals the end of a communication (sequence) for the default channel)

• that messages involving tokens as defined here must be sent on the default channel for they are considered control messages (i. e. messages like identification requests, responses to those, opening channels, signalling the end of a communication (sequence))

• that devices should respond with the protocol message indicating the end of communication for tokens they do not understand to potentially save other devices unnesessary waiting times

• that devices must not respond to the protocol message indicating the end of communication because doing so could create message loops

Reference Implementation: A Tethering Device

The tethering device can be queried for the UUIDs of prims to which chains or leashes can be attached. The token to query the device is "tether". The device replies with the token "tether point", followed by the UUID of a chaining point. Each chaining point is reported in a seperate response message, one chaining point per message. When all chaining points have been reported, this devices sends a RFEDIP_protEND control message.

list getlinknumbersbyname(string name)
{
	integer n = llGetObjectPrimCount(llGetLinkKey(llGetLinkNumber()));
	list numbers = [];
	name = llToLower(name);

	if(n > 1)
	{
		while(n)
		{
			if((~llSubStringIndex(llToLower(llList2String(llGetLinkPrimitiveParams(
			                                    n, [PRIM_NAME]), 0)), name)))
			{
				numbers += n;
			}

			--n;
		}
	}
	else
	{
		if((~llSubStringIndex(llToLower(llGetObjectName()), name)))
		{
			numbers += n;
		}
	}

	return numbers;
}

key kThisDevice;
list lHooks;

default
{
	state_entry()
	{
		// remember the link numbers of the chain targets
		//
		lHooks = getlinknumbersbyname("hook");

		if(!(llGetListLength(lHooks)))
		{
			lHooks = (list)llGetLinkNumber();
		}

		kThisDevice = llGetLinkKey(llGetLinkNumber());
		llListen(-20131224, "", NULL_KEY, "");
	}

	changed(integer w)
	{
		// maybe do something else here if you need to sit on
		// this device
		//
		if(w & CHANGED_LINK)
		{
			kThisDevice = llGetLinkKey(llGetLinkNumber());
			lHooks = getlinknumbersbyname("hook");

			if(!(llGetListLength(lHooks)))
			{
				lHooks = (list)llGetLinkNumber();
			}
		}
	}

	listen(integer channel, string name, key other_device, string _MESSAGE)
	{
		if("identify" == _MESSAGE)
		{
			// Indistinctively answer queries that want to
			// detect this device: The answer goes to the
			// sender (i. e. other_device) and looks like:
			//
			// "<sender-uuid>|<recipient-uuid>|RFEDIP_sVERSION|RFEDIP_protIDENTIFY"
			//
			// For the device that receives the answer to
			// the request to identify, the <sender-uuid>
			// is the UUID of this device.
			//
			llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice,
			              other_device, "RFEDIP-1.0", "identity"], "|"));
			return;
		}

		// From here on, received messages are expected to
		// look like:
		//
		// "<sender-uuid>|<recipient-uuid>|RFEDIP_sVERSION|<token>[|parameter|parameter...]"
		//
		// <sender-uuid> is the UUID of the device sending the
		// message (i. e. other_device); <recipient-uuid> is
		// the UUID of the recipient, i. e. of this device
		//
		// Please do not confuse incoming messages with
		// outgoing messages!

		// The received message is put into a list for further
		// processing:
		//
		list payload = llParseString2List((_MESSAGE), ["|"], []);

		// Attempt to verify whether the message looks valid:
		//
		if(llGetListLength(payload) < 4)
		{
			return;
		}

		// Attempt to make sure that the message is for this
		// device:
		//
		// + ignore messages that appear not to be sent by the
		//   device they claim to be sent from by verifying
		//   the sender given in the message with the actual
		//   sender
		//
		// + ignore messages that appear not be destined for
		//   this device by verifying the recipient given in
		//   the message with what this device actually is
		//
		// + ignore messages that request a different version
		//   of the protocol by verifying the protocol version
		//   given in the message --- in this example, a check
		//   for what is considered a "sufficient version" is
		//   applied
		//
		if((llList2Key(payload, 0) != other_device)
		   || (llList2Key(payload, 1) != kThisDevice)
		   || !(~llSubStringIndex(llList2String(payload, 2), "RFEDIP")))
		{
			return;
		}

		// From here on, the capabilities of the device can be
		// implemented.

		// Here: Report the chain target points and send of of
		// communication message.
		//
		if(llList2String(payload, 3) == "tether")
		{
			integer n = llGetListLength(lHooks);

			while(n)
			{
				--n;
				llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice,
				              other_device, "RFEDIP-1.0", "tether point", llGetLinkKey(llList2Integer(lHooks,
				                      n))], "|"));
			}
		}

		if(!(llList2String(payload, 3) == "msg_end!"))
		{
			// when receiving messages not handled by this device,
			// indicate end of communication to potentially save
			// other devices unnecessary waiting times
			//
			// do not answer with com/end to com/end messages to avoid message loops!
			//
			llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice, other_device, "RFEDIP-1.0", "msg_end!", -20131224], "|"));
		}
	}

	on_rez(integer p)
	{
		// UUID changes when rezzed
		//
		kThisDevice = llGetLinkKey(llGetLinkNumber());
	}
}

You can find the source for this device in the git repository and further documentation in this article.

Reference Implementation: A device using chaining points

This device can send queries for the UUIDs of prims to which chains can be attached. The token used for the query is "tether". This device expects answers to this query to use the token "tether point", followed by the UUID of the point as parameter. It expects devices that have received a query to indicate that all their UUUIDs have been reported by sending a a RFEDIP_protEND control message, regardless whether any points have been reported or not.

This device can be queried for the UUIDs of prims to which chains can be attached. The token to query the device is "tether". The device replies with the token "tether point", followed by the UUID of a chaining point. Each chaining point is reported in a seperate response message, one chaining point per message. When all chaining points have been reported, this devices sends a RFEDIP_protEND control message.

When this device has not created chains itself, it does not report its chain target points but sends a RFEDIP_protEND control message instead.

The implementation happened to grow quite a bit larger than what I had expected. What I expected is that it is simple to link a couple chains from an object to a couple points that are somewhere around. Pfff!

It is simple to link each chain to the point closest to it. When you do that, the result looks retarded in most cases because the chains may get entangled or go across the object, and several chains may go to the same point. That was ridiculous and not acceptable.

Humans solve the problem without thinking. For example, they tie their boats to the tethering points around the berths their boats are in without entangling all the ropes. They do not attach the ropes in such a way that they go across the boat. Humans are flexible and sometimes cross over some ropes or have multiple ropes go to the same point when the conditions let this appear to be advisable. The result never looks retarded because the way it´s done makes sense.

Even children do it right. I couldn´t figure out how I would do it because I would just do it. People I asked didn´t know how to do it, either. The problem is too simple. This made it surprisingly difficult to create an algorithm which yields results that don´t look retarded for at least most conditions. It took a lot of experimentation and was fun to create.

What this algorithm does, and how it does it, is irrelevant for the purpose of this article. I´ll only put the more relevant part into the article. You can find the whole source in the git repository and further documentation in this article.

default
{
	listen(integer channel, string name, key other_device, string _MESSAGE)
	{
		//
		// This first part is the same as with the tethering device.
		//

		if("identify" == _MESSAGE)
		{
			llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice,
			              other_device, "RFEDIP-1.0", "identity"], "|"));
			return;
		}

		list payload = llParseString2List((_MESSAGE), ["|"], []);

		if(llGetListLength(payload) < 4)
		{
			return;
		}

		if((llList2Key(payload, 0) != other_device)
		   || (llList2Key(payload, 1) != kThisDevice)
		   || !(~llSubStringIndex(llList2String(payload, 2), "RFEDIP")))
		{
			return;
		}

		string token = llList2String(payload, 3);

		//
		// The rest is device specific.  Tokens in received
		// protocol messages trigger various actions to make
		// the device to its job.
		//

		if("tether point" == token)
		{
			// [...]
		}

		if("msg_end!" == token)
		{
			// when all devices have indicated end of communication,
			// create the chains
			//
			if((!!(status & 2)))
			{
				--iDevicesAround;
				iDevicesAround = (((llAbs((iDevicesAround) >= (0))) * (iDevicesAround)) + ((
				                      llAbs((iDevicesAround) < (0))) * (0)));

				if(!(iDevicesAround))
				{
					mkchains();
				}
			}

			return;
		}

		if("identity" == token)
		{
			// when other devices identify themselves, query them for tether points
			//
			++iDevicesAround;
			llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice,
			              other_device, "RFEDIP-1.0", "tether"], "|"));
			return;
		}

		if((!!(status & 4)) && ("tether" == token))
		{
			// answer queries from other devices when this device is chained
			//
			integer _n = llGetListLength(lChains);

			while(_n)
			{
				_n -= 2;
				llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice,
				              other_device, "RFEDIP-1.0", "tether point", llGetLinkKey(llList2Integer(lChains,
				                      (_n)))], "|"));
			}
		}

		if(!("msg_end!" == token))
		{
			// when receiving messages not handled by this device,
			// indicate end of communication to potentially save
			// other devices unnecessary waiting times
			//
			// do not answer with com/end to com/end messages to avoid message loops!
			//
			llRegionSayTo(other_device, -20131224, llDumpList2String([kThisDevice, other_device, "RFEDIP-1.0", "msg_end!", -20131224], "|"));
		}
	}

	touch_start(integer t)
	{
		// [...]
		iDevicesAround = 0;
		// [...]

		// ask other devices to identify
		//
		llRegionSay(-20131224, "identify");
	}

	// [...]
}

The reference implementation is available with some example objects for free on the marketplace.

The code on this wiki page and in the repository is more recent than the code with the example devices.

Documenting rfedip compliant devices you create

Please use this page to document your devices.

Version 1.1

Rfedip version 1.1 is currently being tested. The sources in the repository have already been updated.

Version 1.1 replaces version 1.0.

It has turned out that using a UUID to identify a device is insufficient. The protocol has been extended by inserting another identifier with the UUID. The default for this additional identifier is what llGetScriptName() returns.

Without the additional identifier, problems arise when a prim contains multiple scripts which implement rfedip devices. Imagine you have a prim with the devices A and B. The remote device C queries for rfedip devices and discovers A and B. Device B supports tokens device C works with while device A does not support these tokens. Device C would receive messages indicating the end of communication from device A for the tokens A does not support. But C relies on these messages from device B to decide whether requested data has been fully transmitted or not. Since device C cannot distinguish whether a message was sent by A or by B, C cannot function correctly. The unexpected messages from A may lead to C missing responses from B.

Introducing a uniq identifier for each device now enables device C to distinguish between the devices A and B. Unfortunately, this has required to modify the protocol. Having only one rfedip device per prim, or using seperate channels for instances when multiple devices are in the same prim, have too many disadvantages.

Adding the identifier defeats backwards compatibility. Considering the severe limitations LSL scripts are subjected to, especially memory limitations, future versions of the protocol should be backwards compatible, but are not required to when compatibility cannot reasonably be maintained.

Version 1.1 Reference Implementation: A Tethering Device

This device is the same as with protocol version 1.0. The only difference is that it uses protocol version 1.1. The uniq identifier has been added to the protocol header. The recipient of a message verifies whether the uniq identifier specified by the sender of the message for the uniq identifier of the recipient is identical to the uniq identifier of the recipient. The script looks like this:

// =rfedipdev-tether.i
list getlinknumbersbyname(string name)
{
	integer n = llGetObjectPrimCount(llGetLinkKey(llGetLinkNumber()));
	list numbers = [];
	name = llToLower(name);

	if(n > 1)
	{
		while(n)
		{
			if((~llSubStringIndex(llToLower(llList2String(llGetLinkPrimitiveParams(n, [PRIM_NAME]), 0)), name)))
			{
				numbers += n;
			}

			--n;
		}
	}
	else
	{
		if((~llSubStringIndex(llToLower(llGetObjectName()), name)))
		{
			numbers += n;
		}
	}

	return numbers;
}
key kThisDevice;
list lHooks;

default
{
	state_entry()
	{
		lHooks = getlinknumbersbyname("hook");

		if(!(llGetListLength(lHooks)))
		{
			lHooks = (list)llGetLinkNumber();
		}

		kThisDevice = llGetLinkKey(llGetLinkNumber());
		llListen(-20131224, "", NULL_KEY, "");
	}
	changed(integer w)
	{
		if(w & CHANGED_LINK)
		{
			kThisDevice = llGetLinkKey(llGetLinkNumber());
			lHooks = getlinknumbersbyname("hook");

			if(!(llGetListLength(lHooks)))
			{
				lHooks = (list)llGetLinkNumber();
			}
		}
	}
	listen(integer channel, string name, key other_device, string _MESSAGE)
	{
		if((llGetSubString(_MESSAGE, 0, 7) == "identify"))
		{
			// The incoming message looks like:
			//
			// "identify|<sender-Uniq>"
			//
			// Default for the uniq identifier is what
			// llGetScriptName() returns.  Please see
			// rfedip.h.
			//
			// Indistinctively answer queries that want to
			// detect this device: The answer goes to the
			// sender (i. e. other_device) and looks like:
			//
			// "<this-device-uuid>|<RFEDIP_sTHIS_UNIQ>|<recipient-uuid>|<recipient-Uniq>|RFEDIP_sVERSION|RFEDIP_protIDENTIFY"
			//
			// For the device that receives the answer to
			// the request to identify, <this-device-uuid>
			// is the UUID of this device.
			//
			// With
			//
			//   RFEDIP_RESPOND(<recipient-uuid>, <recipient-Uniq>, <sender-uuid>, <protocol-payload>);
			//
			// an answer is sent to the device from which
			// this device has received the request to
			// identify itself:
			//

			llRegionSayTo(other_device, -20131224,
				      llDumpList2String([kThisDevice, llGetScriptName(),
							 other_device,
							 llList2Key(llParseString2List(_MESSAGE,
										       ["|"], []),
								    1), "RFEDIP-1.1", "identity"],
							"|"));
			return;
		}

		// From here on, received messages are expected to
		// look like:
		//
		// "<sender-uuid>|<sender-Uniq>|<recipient-uuid>|<recipient-Uniq>|RFEDIP_sVERSION|<token>[|parameter|parameter...]"
		//
		// <sender-uuid> is the UUID of the device sending the
		// message (i. e. other_device); <recipient-uuid> is
		// the UUID of the recipient, i. e. of this device
		//
		// same goes for <sender-Uniq> and <recipient-Uniq>
		//
		// Please do not confuse incoming messages with
		// outgoing messages!
		//
		// Parameters can be tokens.  However, this is not
		// recommended.  Send multiple messages rather than
		// multiple tokens in one message.
		//
		// The received message is put into a list for further
		// processing:
		//
		list payload = llParseString2List(_MESSAGE, ["|"], []);

		// Attempt to verify whether the message looks valid:
		//
		if(llGetListLength(payload) < 6)
		{
			return;
		}

		// Attempt to make sure that the message is for this
		// device:
		//
		// + ignore messages that appear not to be sent by the
		//   device they claim to be sent from by verifying
		//   the sender given in the message with the actual
		//   sender:
		//
		// + ignore messages that appear not be destined for
		//   this device by verifying the recipient given in
		//   the message with what this device actually is:
		//
		// + ignore messages that appear not to be destined for
		//   this device by verifying the Uniq identifiers
		//
		// + ignore messages that request a different version
		//   of the protocol by verifying the protocol version
		//   given in the message --- in this example, a check
		//   for what is considered a "sufficient version" is
		//   applied:
		//
		if((llList2Key(payload, 0) != other_device)
		   || (llList2Key(payload, 2) != kThisDevice)
		   || (llList2Key(payload, 3) != llGetScriptName())
		   || !(~llSubStringIndex(llList2String(payload, 4), "RFEDIP")))
		{
			return;
		}

		// From here on, the capabilities of the device can be
		// implemented.
		//

		// extract the token from the rfedip message ...
		//
		string token = llList2String(payload, 5);
		//
		// ... and the uniq identifier of the sender
		//
		string uniq = llList2Key(payload, 1);

		// Report the device type and send end of
		// communication message.
		//
		if("qry-devtype0" == token)
		{
			llRegionSayTo(other_device, -20131224,
				      llDumpList2String([kThisDevice, llGetScriptName(),
							 other_device, uniq, "RFEDIP-1.1",
							 "devtype0-flags", 0], "|"));
			llRegionSayTo(other_device, -20131224,
				      llDumpList2String([kThisDevice, llGetScriptName(),
							 other_device, uniq, "RFEDIP-1.1",
							 "msg_end!", -20131224], "|"));
			return;
		}

		// Report the chain target points and send end of
		// communication message.
		//
		if(token == "tether")
		{
			integer n = llGetListLength(lHooks);

			while(n)
			{
				--n;
				llRegionSayTo(other_device, -20131224,
					      llDumpList2String([kThisDevice, llGetScriptName(),
								 other_device, uniq, "RFEDIP-1.1",
								 "tether point",
								 llGetLinkKey(llList2Integer(lHooks,
											     n))],
								"|"));
			}
		}

		// when receiving messages not handled by this device,
		// indicate end of communication to potentially save
		// other devices unnecessary waiting times
		//
		// do not answer with com/end to com/end messages to avoid message loops!
		//
		if(!("msg_end!" == token))
		{
			llRegionSayTo(other_device, -20131224,
				      llDumpList2String([kThisDevice, llGetScriptName(),
							 other_device, uniq, "RFEDIP-1.1",
							 "msg_end!", -20131224], "|"));
		}
	}
	on_rez(integer p)
	{
		kThisDevice = llGetLinkKey(llGetLinkNumber());
	}
}

The source in the git repository is different from above script in that the uniq identifier is stored in a string to avoid calling llGetScriptName() many times.

You can use something else than the return of llGetScriptName() to generate a uniq identifier. llGetScriptName() has the advantage that it provides uniqness in combination with the UUID of the prim the script is in: Multiple scripts in the same prim cannot have identical names. It is preferable over a hard-coded string because a hard-coded string could lead to ambiguity when two devices in the same prim use the same string. You could use llGenerateKey() instead, with the disadvantages that it probably requires more script memory and that a new key is generated with each call.

Version 1.1 Reference Implementation: A device using chaining points

The device is the same as with protocol version 1.0. The only difference is that it uses protocol version 1.1. You can find the source in the git repository.

Version 1.2

Version 1.2 features the minor addtion of an "OK" message. The token is "rfedipOK" and can be used to indicate that an operation requested through a protocol message has been performed, or to otherwise positively acknowledge a message.

This is not a control message because it doesn´t make much sense to send an acknowledgement for something on the default channel while the communication otherwise goes over a dedicated channel.

The macro "RFEDIP_OK" to send the "OK" message has been added to rfedip.h.

For clarification:

The message indicating the end of communication is to indicate the end of communication as described previously. When data is transmitted in a series of messages --- or in a single message --- the com/end message should be sent to indicate that no further transmissions are to be expected as part of the current response.

The com/end message is also to be sent when the device does not understand a token it has received in a protocol message. Sending the com/end message in such instances clearly indicates that no further transmission is to be expected as part the current response. Insofar an operation has been requested, replying with the com/end message to the request indicates that the operation has not been performed --- or, for example, that a feature is not available.

A com/end message must not be replied to with a com/end message because doing so likely creates a message loop. A response to a request for identification must not be followed by a com/end message because the response is never part of a series of messages. It is sufficient that a device identifies itself, hence an "OK" message must not be used to indicate that the device has identified itself, either.

Other than that, how the "OK" message is used depends on the particular device. For example, a piece of furniture that asks an attachment to create a chain may want to receive an acknowledgement that the chain has been created, so the attachment would send an "OK" message as a response when the chain has been created. When the chain has not been created, the attachment would send a com/end message instead. Unless the furniture receives a com/end message, it could re-send the request to create a chain.

As always, document the devices you create accordingly.

Version Numbering

Version numbers are composed of a leading string "RFEDIP-", followed by an integer representing the major version number and an integer representing the minor version number. The two integers are seperated by a dot (".").

This means that version "RFEDIP-1.115" is a higher version number than "RFEDIP-1.5".

Two macros to obtain the major and minor version numbers from a protocol message converted to a list have been added to rfedip.h. The macros are called "RFEDIP_iVersionMajor" and "RFEDIP_iVersionMinor". They evaluate to integers with the respective version numbers.

rfedip-devices.h

A collection of definitions for rfedip devices is provided with rfedip-devices.h in the git repository. None of the definitions and tokens contained therein are in any way mandatory. They are not part of the specification of the rfedip protocol.

The file is intended to be used to make the implementation of particular rfedip-compliant devices easier. When further devices are created and documented, the tokens used by them can be added to rfedip-devices.h and thus become available to all creators of rfedip devices.

References

• Reference Implementation

• How to make creating LSL scripts easier describes how to preprocess your sources with cpp.

• Git repository for the article that describes how to preprocess your sources with cpp and contains the reference implementations.

• page to document your devices

History

• 2013-12-27: initial page created

• 2013-12-27: tokens changed to something more easily readable; different indentation used for LSL script

• 2013-12-27: tried to improve the "About" section

• 2013-12-29: added second example

• 2013-12-31: replaced second example with an improved version; added suggestion to send an end-of-comminucation message for tokens not understood

• 2013-12-31: added reference to opengate source; removed unnecessary return statement from first example

• 2014-01-04: added reference implementation

• 2014-01-04: made reference implementation available on the marketplace

• 2014-01-04: the code on this page was slightly optimized

• 2014-01-04: bugfix, sigh ...

• 2014-01-04: use PRIM_POSITION instead of PRIM_POS_LOCAL

• 2014-01-04: yet another bugfix

• 2014-01-13: article rewritten

• 2014-01-13: added page to document devices

• 2014-01-16: bugfix: do not reply to com/end messages

• 2014-01-21: protocol version 1.1

• 2014-01-27: protocol version 1.2