###########
Flux réseau
###########



Waarp Manager génère des flux réseaux de plusieurs natures : 

* Des transferts R66 vers les partenaires, en utilisant un client dédié, pour envoyer la
  configuration des flux aux partenaires gérés par Manager ;
* Des requêtes HTTP REST vers les serveurs Waarp R66 gérés pour récupérer leur
  historique de transfert, et stopper ou relancer les transfferts existants :
* Des flux HTTP des utilisateurs vers l'interface Web de Waarp Manager.


.. uml:: 
   
   title Flux générés par Waarp Manager

   actor Administrateur
   actor Utilisateur
   
   rectangle "Site 1" {
      agent "Waarp Manager" as MAN
      agent "Client R66" as CR66
   }

   rectangle "Site 2" {
      agent "Waarp R66 Server 1" as R661
      agent "Waarp R66 Server 2" as R662
      agent "Waarp R66 Server 3" as R663
   }
   
   Administrateur --> MAN: HTTP
   Utilisateur --> MAN: HTTP
   MAN ~right~> CR66
   CR66 --> R661: R66
   CR66 --> R662: R66
   CR66 --> R663: R66
   MAN --> R661: HTTP
   MAN --> R662: HTTP
   MAN --> R663: HTTP
   



.. index:: Proxy HTTP (Site)

.. _concepts_proxy_http:

Utilisation d'un proxy HTTP
===========================

Par défaut, Waarp Manager interagit avec Les serveurs Waarp R66 en leur
addressant des requêtes REST directes dans plusieurs cas :

* Pour récupérer leur historique de transferts ;
* Pour arrêter/relancer des transferts.

.. uml::

   title Par défaut

   rectangle "Site A" {
     (Waarp Manager) as (MAN)
   }

   rectangle "Site B" {
     (Serveur A) as (A)
     (Serveur B) as (B)
     (Serveur C) as (C)
     (Serveur D) as (D)
     (Serveur E) as (E)
     (Serveur F) as (F)
   }

   (MAN) --> (A)
   (MAN) --> (B)
   (MAN) --> (C)
   (MAN) --> (D)
   (MAN) --> (E)
   (MAN) --> (F)


Cela implique de nombreuses connexions directe. Selon les normes en vigueur
dans une organisation, cela peut rendre les firewalls fastidieux à configurer.

L'utilisation d'un Proxy HTTP (un simple serveur HTTP par lequel transitent
toutes les requêtes à destination des serveurs R66) peut permettre de résoudre
cet inconvénient.

.. uml::

   title Avec un proxy

   rectangle "Site A" {
     (Waarp Manager) as (MAN)
   }

   rectangle "Site B" {
     (Proxy HTTP) as (PRX)
     (Serveur A) as (A)
     (Serveur B) as (B)
     (Serveur C) as (C)
     (Serveur D) as (D)
     (Serveur E) as (E)
     (Serveur F) as (F)
   }

   (MAN) --> (PRX)
   (PRX) --> (A)
   (PRX) --> (B)
   (PRX) --> (C)
   (PRX) --> (D)
   (PRX) --> (E)
   (PRX) --> (F)


Déclaration d'un proxy
----------------------

Dans Waarp Manager, un proxy se déclare pour un site donné, dans l'écran de
paramétrage du site :

 .. figure:: ../_static/img/site_edit_proxy.png

    Définition d'un proxy pour un site

Une fois cette déclaration faite, toutes les requêtes REST émise à destination
du partenaires :

* sont envoyées au proxy défini pour le site du partenaire,
* l'en-tête HTTP indiqué dans le paramètre ``header``  contient l'addresse et le
  port du partenaire de destination (par défaut, :http:header:`Host` est
  utilisé).


Paramétrage du proxy
--------------------

Le proxy doit utiliser l'en-tête :http:header:`Host` pour déterminer ladresse et
le port de redirection de la requête. Waarp Manager utilise *toujour* HTTPS pour
émettre les requêtes. Ceci doit être pris en compte dans la configuration du
proxy.

Voici un example de configuration minimale pour Nginx :

.. code-block:: nginx

   server {
      listen       12345 ssl;
      server_name  localhost;
      ssl_certificate     /path/to/r66-server.crt;
      ssl_certificate_key /path/to/r66-server.key;

      location / {
         proxy_pass https://$http_host$request_uri;
      }
   }