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