Link to LightMSGP specifications index.

LightMSGP Specification Version 1 (LightMSGP_v1)

LightMSGP_v1 is a cleanup and generalization of LightMSGP_v0, but ITS ROUTING ALGORITHM IS FUNDAMENTALLY FLAWED!!!. The credits for finding (2013_05_30) the flaw goes to Juhan-Peep Ernits.

Addressing Scheme

Widget instances can asynchronously send messages to each other. Each of the widget instances has a phone number that is unique within an operating system process that contains the instance.

The LightMSGP_v1 specification is explained by an example. The following schematics illustrates a situation, where computers C1, C2 and C3 each run only a single process that uses the LightMSGP_v1. At the schematics the computer C2 has widgets W75, W1, W42 that have phone numbers "W75","W1","W42".

The text of this specification uses a notation, where Computer C2 widget W75 is designated as (C2.W75).

Each of the widgets has its instance specific (usually type specific) set of message receiving methods.

A message that is sent by (C1.W2) to (C1.W3) message receiving method "receiver_52" and is expected to be answered by the (C1.W3) by sending a message to (C1.W2) message receiver method "receiver_x44", has a message path of rceiver_x44.W2.W3.rceiver_52. The response message from the (C1.W3) to the (C1.W2) has exactly the same path, except that the path is interpreted in a reverse order, from right to left.

If the (C1.W2) does not request a reply, then the path would be /dev/null.W2.W3.rceiver_52.

The message path is encoded as an array of strings. For example, the rceiver_x44.W2.W3.rceiver_52. is encoded as:


The LightMSGP_v1 message class has the following mandatory public fields:
s_session_ID -- A random string, preferably a GUID

s_msg_ID -- A random string, preferably a GUID

s_query_msg_ID -- If the current message is used for transmitting an answer to a "question" (a query), then this field contains the value of the s_msg_ID of the message instance that contained the "question". Otherwise it is expected to equal "/dev/null".

ar_msg_path -- The array.

i_msg_path_cursor -- An integer from the range of [0,(ar_msg_path.length-1)].
It indicates the message location on the message path.
0 stands for the leftmost receiver method in the path.

If the (C1.W2) sends the message to (C1.W3), then the (C1.W2) updates the i_msg_path_cursor so that when the (C1.W3) receives it, the i_msg_path_cursor indicates the location of the (C1.W3) on the message path.

b_increment_i_msg_path_cursor -- A boolean that determines the moving direction that the message on the message path.

x_data -- The data, which can be of any type, except in the case of inter-process message exchange. In case of the inter-process message exchange, the x_data must reference a hashtable that has only strings as keys and values. It is OK for the hashtable to be empty.

In the case of the illustration, the (C1.W3) is a gateway to the computer C2. Before forwarding a message to another process, a gateway modifies the path of the message by replacing its own phone number with the phone number of the receiving gateway. For example, if the(C1.W2) were to send a message to (C2.W1) message receiving method "receiver_72" and the (C1.W2) expected the answer to be sent to its method "rceiver_x44", then the (C1.W2) would write an address


Prior to forwarding the message to (C2.W42) the (C1.W3) converts the address to


Gateways are allowed to disconnect themselves from one gateway and reconnect themselves to another gateway, but the maximum amount of simultaneous connections that the addressing scheme of the LightMSGP_v1 supports is 1.

Message Serialization Format

Gateways are required to convert the message instances to and from ProgFTE_v1 strings.

The keys of the hashtable match with the field names of the message instance, except for the ar_msg_path. The ar_msg_path is placed to the hashtable by using the following keys:

i_ar_msg_path_length -- The number of elements in the ar_msg_path.

ar_msg_path_0 -- ar_msg_path[0]

ar_msg_path_1 -- ar_msg_path[1]

ar_msg_path_< array index > -- ar_msg_path < array index >