Serveur d'impression

Architecture · excitant-io / imprimante Wiki · GitHub – Bien choisir son serveur d impression

Par Titanfall , le 13 janvier 2020 - 4 minutes de lecture

Le système d'impression est conçu pour fonctionner sans serveur central et sans source unique de contenu d'imprimante. Il y parvient en utilisant des URL d'imprimante pour identifier et envoyer du contenu aux imprimantes.

Tout d'abord, une terminologie:

  • UNE serveur principal est le serveur qui gère la pixellisation du contenu pour les imprimantes et qui sert ce contenu pour les imprimantes
  • UNE service de contenu hôtes (et PUBLIERs) les URL des pages contenant du contenu à imprimer
  • UNE imprimante est vraiment la combinaison du périphérique d'impression réel, et quelle que soit l'électronique (comme Arduino) qui le connecte au serveur principal.

Voici comment tout s'imbrique:

Envoi de contenu à une imprimante

Dans sa forme la plus simple, il existe une seule imprimante, connectée à un seul serveur principal, avec un seul fournisseur de contenu:

L'imprimante interroge le serveur principal à intervalles réguliers, vérifiant le contenu à imprimer. S'il n'y en a pas, le backend envoie simplement une réponse vide (Longueur du contenu: 0), que l'imprimante ignorera ensuite. L'URL que l'imprimante interroge est composée de l'URL de base du serveur principal (http: // backend1) et l'ID unique de l'imprimante (abc123 dans ce cas) — http: // backend1 / printer / abc123

À tout moment, un service de contenu peut publier sur le URL d'impression, qui est également composé de l'URL du serveur principal et de l'ID de l'imprimante – http: // backend1 / print / abc123.

Lorsqu'un service de contenu envoie une demande contient également un url , qui pointe vers le contenu qui doit finalement être imprimé. Dans ce cas, le url le paramètre est http: // content / 789xyz. Cette URL doit contenir autant d'informations que le service de contenu l'exige pour déterminer correctement le contenu de cette imprimante. Par exemple, il peut également contenir l'ID d'imprimante, ou un ID utilisateur, ou tout autre paramètre qui pourrait être nécessaire.

(Normalement, cette URL sera servie par le service de contenu lui-même, bien que ce ne soit pas strictement nécessaire; ce qui est important, c'est que l'URL soit accessible au serveur principal.)

Le serveur principal effectue ensuite une demande asynchrone pour cette URL, et une fois qu'il reçoit une réponse, le serveur principal est responsable de la pixellisation.

Une fois ce processus terminé, la prochaine fois que l'imprimante interrogera le serveur principal, la réponse ne sera pas vide – elle contiendra les données de l'imprimante que l'imprimante pourra enfin imprimer.

Plus d'une imprimante

Étant donné que les imprimantes ont des ID uniques, plusieurs imprimantes peuvent être gérées par un seul serveur principal. Tant que le service de contenu connaît les URL d'imprimante uniques pour chaque imprimante, il peut envoyer de manière fiable un contenu spécifique à chaque imprimante individuellement.

Dans cet exemple, le service de contenu envoie le contenu à http: // content-a / 789xyz à l'imprimante abc123, puis envoie le contenu à l'adresse http: // content-a / 715jkl à l'imprimante bcd234. Le serveur principal est chargé d'offrir le contenu correct à chaque imprimante, en fonction de l'URL qu'ils interrogent.

Services de contenu multiples

Naturellement, de nombreux services de contenu totalement indépendants peuvent envoyer des données à une seule imprimante.

Dans cet exemple, il existe deux services de contenu, à http: // content-a et http: // content-b respectivement. S'ils connaissent tous les deux l'URL de la même imprimante (http: // backend1 / print / abc123), ils peuvent alors tous les deux lui envoyer du contenu.

Le serveur principal ne se soucie pas vraiment que les deux demandes de contenu proviennent de services différents; parce que le url Le paramètre envoyé inclut également l'hôte, ces URL peuvent être servies à partir de n'importe quel hôte, sur n'importe quel réseau accessible au serveur principal.

Plusieurs serveurs principaux

Pour vraiment démontrer la nature distribuée et fédérée de cette architecture, considérons l'exemple ci-dessous, où il existe plusieurs imprimantes et plusieurs serveurs principaux.

Le service de contenu a été informé de deux imprimantes: http: // backend1 / print / abc123 et http: // backend2 / print / def456.

De manière similaire au serveur principal indépendant du service décrit ci-dessus, le service de contenu est également backend-agnostique. Chaque URL d'imprimante comprend un hôte qualifié complet et lorsque le service de contenu envoie son PUBLIER demande, il n'a pas à se soucier du serveur d'arrière-plan qui traite finalement les demandes vers cette URL d'imprimante.

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.