Meilleure réponse
SIGPIPE est le signal « tuyau cassé », qui est envoyé à un processus lorsquil tente décrire dans un tuyau dont lextrémité de lecture a fermé (ou lorsquil tente décrire sur une socket qui nest plus ouverte à la lecture), mais pas vice versa . Laction par défaut est de terminer le processus.
Ce comportement est utile pour les cas typiques dexécution de processus dans des pipelines. Si vous exécutez foo | bar, vous ne pourrez jamais voir la sortie de foo directement — elle devient lentrée de bar et vous voyez la sortie de bar. Cela signifie que si, par exemple, bar meurt, alors il ny a aucun intérêt à foo de continuer à produire une sortie. Cela peut se produire soit parce que bar a échoué, soit parce quil na plus besoin dentrée (par exemple, sil analyse son entrée pour sassurer quil ny a pas derreur, il peut sarrêter après avoir trouvé le premier).
Imaginez ce qui se passerait si SIGPIPE nexistait pas et que bar mourrait (que ce soit à cause dune erreur ou parce quil avait simplement décidé de quitter ). foo continuerait à sexécuter et il devrait recevoir un code derreur lors de la tentative décriture. Il peut lignorer et continuer à fonctionner, ne laissant à lutilisateur aucune indication évidente que la condition éventuellement anormale de la fin de bar sest produite en premier. Lorsque foo est tué par SIGPIPE, le shell le détectera à laide de lune des fonctions wait(), et affichera un message «Broken pipe» ou similaire.
Dun autre côté, si foo meurt en premier, cest le cas habituel; il ferme la fin décriture, puis bar atteindra simplement lEOF et se terminera normalement.
Réponse
OpenConfig est une collection de modèles YANG standard de lindustrie pour la configuration et la gestion qui seront pris en charge nativement sur les plates-formes matérielles et logicielles de réseau.
Il est devenu très coûteux pour les opérateurs de réseau de maintenir leurs cadres automatisés pour les déploiements multi-fournisseurs.
Bien quil existe de nombreuses interfaces de transport standard, il ny a pas de représentation de données standard (exemple, fournisseur-A et fournisseur-B peuvent prendre en charge des interfaces standard (comme XML, REST, NETCONF …), mais données clé-valeur ne sont pas les mêmes. vendor-A pourrait représenter la clé dinterface comme « intf » et vendor-B pourrait représenter la clé dinterface comme « interface »)
Donc chaque fois quun opérateur de réseau ajoute / met à jour un nouveau périphérique dans leurs déploiements de différents fournisseurs, ils doivent mettre à jour leur cadre automatisé et écrire un traducteur pour convertir le fournisseur-speci représentation des données fic à la représentation des données client.
Certains opérateurs de réseau comme Google, AT&T, BT, Microsoft … travaillent à pousser ces traducteurs vers le fournisseur. Les opérateurs ne se soucient pas de la manière dont ils obtiennent les données, mais ont besoin de données dans une représentation commune afin que leurs outils puissent comprendre et analyser les données facilement.
Le modèle YANG est utilisé pour définir ces modèles de données standard. Vous pouvez consulter certains modèles de yang standard @ openconfig / public
YANG (Yet Another Next Generation) est un langage de définition de données.