Ответ: [Moims-sc] Options for MO MAL Binding to HTTP Transport

[Кудрин Леонид Витальевич]

Dear Mehran,

I respond on given questions:

а) In our organization there is an order, according to which one:

  i) In each case of a integration in network of organization of computers, ports of which one
should be accessible from the Internet, the administrative solution is received 
( the beginning and termination date of the access, quantity demanded 
IP addresses and address of ports, accessible from the Internet,) automation of organization
of process is not supposed;

ii) the fixed addresses for a demanded address grid are excreted;

iii) for each reference from the Internet to given ports given
addresses the traffic is routed to these ports.

b) it is seemed to me necessary for MAL to http binding to take
option 3 because in a series of cases (for example interplay SCC 
& GS) the leased lines without firewalls will be used.

For organization of Long Polling to me is seemed elegant solution
on the base of shared memory in php (http://habrahabr.ru/post/128535). 

With best regards, Leonid Kudrin.


> -----Исходное сообщение-----
> От:		moims-sc-bounces at mailman.ccsds.org [SMTP:moims-sc-bounces at mailman.ccsds.org] от имени Mehran.Sarkarati at esa.int
> Отправлено:	13 августа 2015 г. 17:53
> Кому:		moims-sc at mailman.ccsds.org
> Тема:		[Moims-sc] Options for MO MAL Binding to HTTP Transport
> 
> Dear SM&C WG, 
> 
> As mentioned during the technical meetings in Pasadena and in the last web-ex, we have started the work on ESA side to define a binding between MAL and HTTP transport. 
> 
> The main motivation for this binding is to use mainstream Internet infrastructure on the ground. 
> HTTP protocol is based on a request/response model. 
> For all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS, there is a simple mapping to the HTTP Request/Response model. 
> 
> It gets more complicated for the above mentioned three interaction patterns, when the provider needs to asynchronously initiate a connection to the consumer for delivering a response (request in the other direction). This is specially problematic when the consumer/provider are behind firewalls and also when consumers are dynamically added and removed (hence the firewalls cannot be configured statically). 
> The options we have been discussing are: 
> 
> a) implement a mapping to pure HTTP request/response model for all MAL interaction patterns. For INVOKE, PUSUB and PROGRESS use active/long poling if the consumer is not addressable or behind a firewall (the OASIS WS Make Connection specification can be the model, which uses additional headers to correlate the messages). 
> b) implement a mapping to HTTP request/response for all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS. For these use web-sockets. Web-Sockets are a different protocol than HTTP. It is a message oriented bi-directional protocol on top of tcp/ip. It uses HTTP for initiating the connection and then establishes a bi-directional connection, using the tcp/ip channel below, which was opened by the HTTP. 
> 
> Long polling is clearly less elegant than web-sockets. At the other side for many of our space domain scenarios the consumer and provider are known to each other and the firewalls must be configured anyway. 
> If I take the example of ESA data distribution systems (DDS/EDDS) on the DMZ, even for making a simple http request/response to the DDS, the consumer IP address must to be added to a white list. 
> 
> The scenarios translate therefore to: 
> 
> 1. HTTP Request/Response based mapping to all MAL interaction patterns: This is either when 
>         a) there are no firewalls involved (not very realistic) : No polling involved, simple http request/response 
>         b) consumer and provider are known up front and firewalls are configured accordingly to allow the traffic pass through in both directions (in my opinion more likely/realistic case): > no polling involved, simple http request/response 
>         c) consumers are added and removed dynamically at run-time and firewalls do not allow out-bound connection initiation from provider side: Only for this particular case pooling techniques shall be adopted on top of simple HTTP request/response pattern 
> 
> 2. HTTP Request/Response based mapping to all MAL interaction patterns except for INVOKE/PROGRESS and PUBSUB for which web-sockets shall be used: this would use web-sockets for any scenario (even for scenario a and b, where it would not be necessary and one could do simple http request/response with no polling) 
> 
> 3. A mixture of 1 and 2. Baseline is (1) but for PUBSUB and PROGRESS the consumer can decide if it wants to use web-sockets or long polling. This would be indicated with a header field in the initiating HTTP request (which is needed for both cases). I am not sure if this 3 option is possible without over complicating the binding. 
> 
> I would like to ask you to 
> 
> a) check the setup of the DMZ and firewalls in your organisation and tell us if in your today's setup the firwall/IDS would let web-socket traffic through or would detect and prevent it for port that is specified as http port (e.g. port 80) 
> b) Which of the three options you think we should take for MAL to http binding. 
> 
> I would appreciate your feedback by mid September. 
> 
> Kind Regards 
> Mehran
> This message and any attachments are intended for the use of the addressee or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the sender.
> 
> Please consider the environment before printing this email. << Файл: ATT154650.txt >>