Handshaking review

[Stefano Seppi]

Since the AlpineBits 2017-10 only the server can transmit the list of the capabilities that are implemented, for the client this functionality isn’t allowed. In order to simplify the server configuration and to optimize the communication between a server ad a client it could be useful to add the possibility to transmit the implemented capabilities also to the client.

[Daniele Gobbetti - Peer GmbH/Srl]

Hello all,

Premise

The aim is to allow the client to announce (send) its supported/desired capabilities[0] and the server to react accordingly.

As discussed during the last developers meeting, an option is to move the handshaking to an XML message instead of relying on HTTP headers.

Please note that I don’t think the two aspects are necessarily related, i.e. we can keep HTTP headers and allow two-way capability discovery

This message is focusing on a possible XML element (and a related new action) that could be added to AlpineBits.

OTA allows to exchange Ping_RQ/Ping_RS messages. It is meant to:

The OpenTravel Ping message pair are used to test application connectivity by sending some specific text and determining if the 
receiving application is able to echo back that same text. The free-text data that is passed in the request is expected to be 
echoed back in the response message.

The Request contains only a single element EchoData, while the Response contains the same element and the usual combination of Success/Warnings/Errors.

The main limitations, if we want to respect the OTA “spirit” is that:

• EchoData is defined as: The free-text data that is to be echoed back that indicates the ping request was accepted and processed.
  • no sub-elements are foreseen nor accepted by OTA schemes, hence we need to fit everything in a plain string
  • the free-text has to be echoed back, so no alteration is possible

Despite all the aforementioned limitations, I couldn’t find an alternative element suited for this kind of handshaking, and I believe we can still make it work.

Handshaking proposal

1. The client sends a Ping_RQ to the server. The EchoData element contains a string with the capabilities. Instead of the legacy capabilities string (OK:….), this one is prefixed with the AlpineBits version the capabilities are referring to and terminated by a newline.
2. The server replies with a Ping_RS message. The EchoData element contains the intersection between client-requested and server-supported capabilities.
   • If there is a perfect match with the client capabilities, the EchoData element is preserved (this is important to respect the spirit of OTA), the response should also contain a Success element
   • If there is a partial match, the EchoData contains a subset of Client supported capabilities, the response should also contain appropriate Warnings
   • If the communication is not possible at all, the response should contain an Error (or a blocking Warning)

Let me repeat again that I am using the legacy capabilities string as a concept, not literally, as I believe they should be adapted to this use case.

Known Issues / room for improvements

If a client supports multiple AlpineBits versions, it could add multiple capability “lines” (each capability string is terminated by a newline), however in this scenario almost no exchange would yield a Success outcome.

This proposal does not allow the discovery of server capabilities that are not supported by the client, but I don’t think this is a problem (they would not be used anyway).

During the discussion the new handshaking was expected to deal with additional information exchange (e.g. URI for pushing messages to the Client). This can be added at a later stage, once we agree on a way to map the handshaking of already existing information.

Conclusions

At this stage, I believe we must agree upon some basic aspects:

• do we want to use Ping_RQ/Ping_RS for handshaking?
  • we must accept the limitation of exchanging a text-only message, and work around this limitation
• is the intersection between client and server supported features enough?
• is it needed to exchange capabilities for more than one AlpineBits version in a single handshaking?

Looking forward to discussing this on Thursday.

Best regards,
Daniele Gobbetti

[0] : I use the word capabilities as concept, not necessarily referring to the current capabilities of AlpineBits servers.

—

On 08/02/2018 15:28, Stefano Seppi wrote:

Since the AlpineBits 2017-10 only the server can transmit the list of the capabilities that are implemented, for the client this functionality isn’t allowed. In order to simplify the server configuration and to optimize the communication between a server ad a client it could be useful to add the possibility to transmit the implemented capabilities also to the client.

--
You received this message because you are subscribed to the Google Groups "AlpineBits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+...@googlegroups.com.
To post to this group, send email to alpin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/321be201-92d4-49d5-be18-462a5f4dce70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

​

--

	Daniele Gobbetti Head of Development & Operations
	Peer GmbH/Srl - www.peer.biz Tel. +39 0471 631080 - Fax +39 0471 631724

[Daniele Gobbetti - Peer GmbH/Srl]

I added a proposal for the JSON content of the message in the gitlab issue: https://gitlab.com/alpinebits/developers-kit/issues/4


Best regards,
Daniele Gobbetti

--

To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/cb67d3ac-058e-bff7-633e-1011aca71036%40peer.biz.

For more options, visit https://groups.google.com/d/optout.