Galaxy_TOC

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:

ar_msg_path[0]="rceiver_x44"
ar_msg_path[1]="W2"
ar_msg_path[2]="W3"
ar_msg_path[3]="rceiver_52"


The LightMSGP_v1 message class has the following mandatory public fields:
xxxx
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

rceiver_x44.W2.W3.W1.receiver_72

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

rceiver_x44.W2.W42.W1.receiver_72.


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:

xxxx
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 >