7. Operational Considerations
7. Operational Considerations
7.1. Load Management
Un service push doit souvent maintenir énormément de connexions TCP ouvertes. Les déplacer entre instances peut être nécessaire.
Le user agent MUST prendre en charge 307 (Temporary Redirect) [RFC7231] pour la redistribution lors d'une nouvelle souscription.
La redistribution peut aussi utiliser les services alternatifs HTTP [RFC7838], en conservant les mêmes URI. Le user agent peut utiliser GOAWAY après avoir établi une connexion de remplacement.
7.2. Push Message Expiration
Le stockage selon TTL peut être volumineux. Le service n'est pas obligé de conserver indéfiniment ; il peut indiquer la durée prévue via TTL (5.2).
Un user agent qui ne surveille pas activement ne recevra pas les messages expirés pendant cette période.
Les messages stockés non livrés sont livrés à la reprise de la surveillance. Ils SHOULD inclure Last-Modified [RFC7232] (moment de la demande de livraison).
Un GET sur un abonnement ne contenant que des messages expirés se comporte comme s'il n'y avait jamais eu de message.
Pour limiter taille et nombre, le service MAY renvoyer 413 [RFC7231] si le corps est trop grand. Il MUST NOT renvoyer 413 pour un corps de 4096 octets ou moins.
Pour limiter le nombre, le service MAY raccourcir le TTL par rapport à la demande. Après acceptation, il MAY expirer avant le TTL annoncé ; si un accusé était demandé, il MUST renvoyer une réponse d'échec (6.2).
7.3. Subscription Expiration
Il peut être nécessaire de terminer les abonnements pour les rafraîchir (messages et accusés).
Le service MAY expirer un abonnement à tout moment. Les requêtes en cours sur une ressource expirée (6 ou 6.3) MUST être signalées par 404.
Tentative d'envoi vers un abonnement expiré : MUST 404.
Le user agent peut DELETE l'URI d'abonnement message ; le serveur d'application peut DELETE l'abonnement aux accusés.
7.3.1. Subscription Set Expiration
Le service MAY expirer un ensemble et MUST alors expirer tous les abonnements qu'il contient. Requête en cours sur l'ensemble (6.1) : MUST 404.
DELETE sur l'URI de l'ensemble MUST supprimer aussi tous les abonnements de l'ensemble.
Si un abonnement membre expire ou est supprimé, il MUST être retiré de l'ensemble.
7.4. Implications for Application Reliability
Sans livraison fiable sur réseaux intermittents ou applis défaillantes, l'appareil doit accuser réception directement auprès de chaque serveur d'application, ce qui consomme plus d'énergie.
La fiabilité compte si les messages portent un état critique ; sinon retransmissions, sondage et resynchronisation coûtent cher.
Les accusés de livraison évitent de construire des canaux de secours qui annulent les bénéfices du push.
Pour des messages éphémères ou rapidement remplacés, la fiabilité peut être moins critique.
7.5. Subscription Sets and Concurrent HTTP/2 Streams
Si le service impose les ensembles, il MAY limiter les flux concurrents avec SETTINGS_MAX_CONCURRENT_STREAMS [RFC7540]. Le user agent MAY n'avoir qu'un flux pour gérer les abonnements et un par ensemble retourné, ce qui peut sérialiser les souscriptions.