[Moims-sc] Mission Operations - MAL Binding to TCP/IP Transport and Split Binary Encoding

[Champsavoir Nicolas]

Dear Mehran, SM&C WG Members.

Please find bellow some comments from ScalAgent regarding the MAL Binding to TCP/IP. ScalAgent is the French company behind the MAL Java API and MAL Binding to Spacepackets. They are currently working on the MAL Binding to ZeroMQ.

Best regards,
Nicolas

-------------------- Original Email From ScalAgent --------------------

You will find below some comments about the MAL TCP/IP blue book draft.
Our reading has not been exhaustive as it was incidental to our own writing of the MAL ZMTP draft.

1- there is an issue that comes from the Space Packet blue book itself, which has been copied into the MAL TCP/IP draft. We suggest to modify it as described in section 3.5.2.2 of the MAL ZMTP draft. It should perhaps be modified in the MAL SPP blue book, if possible. The issue is explained below.

The 'message body mapping' specified in the MAL Space Packet binding (section 3.5) does not accept a NULL list when encoding a body element of a Publish/Notify message (section 3.5.3.3). However, encoding a NULL list happens to be the most efficient way to encode a List< <<Update Value Type>> > when all the updates are NULL, or when the update type is not defined.

An example is a COM::Archive provider publishing COM events. As the events published by Archive have no body (Object Body Type "not used") then the update list typed List<MAL::Element> should be NULL.

This issue is raised by running the COM prototype on top of the MAL Space Packet binding, as the value NULL is not accepted for a Publish/Notify message body element. Therefore, an arbitrary empty list needs to be passed instead of NULL, which is less efficient and less clean.

2- in the MAL TCP/IP draft an improvement of the SPP encoding is proposed, relative to the encoding of the actual type of an abstract typed element (section 5.2, relative to section 5.2.3 of MAL SPP). We are not convinced by the potential gain of this optimisation.

If we properly understand the proposal and the varint encoding, the figure below details the bytes of the concatenated field (above) and the encoded bytes of the varint (below).

It appears that for any area number greater than 1, the eighth byte of the varint will be necessary, leading to no optimisation. The gain is then

  *   limited to a single byte for types defined in the area MAL
  *   null for most others
  *   potentially a loss for an area number greater than 256
  *   limited to 1 per message (rule of abstract type)
If the optimisation of this field is necessary, there is certainly a better way of taking advantage of the great number of 0s in it.

3- the rules in sections 4.4 and 4.6 create a strong and prescriptive mapping between the port parts of the service URIs and the port parts of the TCP headers. We are not definitely sure of the consequences of this choice, but it looks like it limits the choices left to the implementations. Here are some related remarks :

  *   the TCP/IP protocol is completely symmetric, making it legal to create the two connections (H1:p1 -> H0:p0) and (H0:p0 -> H2:p2). However it may be hard to build such connections through a specific API. If H0:p0 is bound as a listening socket, is it possible to bind another socket on the same port to connect it to some other distant host ? As a result implementation will probably have to specialize inboud and outbound ports.
     *   if a service is a provider on one side, and a consumer on another side, what will be its URI ?
     *   another possible consequence is that it could be hard to recover from a connection interruption. The service provider will have to wait for the user to restablish the connection.
Best regards,




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20151113/05778825/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 43 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20151113/05778825/attachment.gif>