Cel mai bun răspuns
SIGPIPE este semnalul „țeavă spartă”, care este trimis unui proces atunci când încearcă să scrie pe o țeavă al cărei capăt de citire are închis (sau când încearcă să scrie într-un soclu care nu mai este deschis pentru citire), dar nu invers . Acțiunea implicită este de a termina procesul.
Acest comportament este util pentru cazurile tipice de rulare a proceselor în conducte. Dacă rulați foo | bar, atunci nu veți vedea niciodată direct ieșirea foo — devine intrarea în bar și vedeți ieșirea bar. Aceasta înseamnă că, de exemplu, dacă bar moare, atunci nu are niciun punct ca foo să continue să producă ieșire. Acest lucru se poate întâmpla fie pentru că bar a eșuat, fie pentru că nu mai are nevoie de intrare (de exemplu, dacă își scanează intrarea pentru a vă asigura că nu există erori, se poate opri după găsire primul).
Imaginați-vă ce s-ar întâmpla dacă SIGPIPE nu ar exista și bar a murit (fie din cauza unei erori, fie pentru că pur și simplu a decis să părăsească ). foo va continua să ruleze și va trebui să primească un cod de eroare la încercarea de a scrie. S-ar putea să ignore acest lucru și să continue să ruleze, lăsând utilizatorul fără indicații evidente că starea posibilă anormală de bar a avut loc mai întâi. Când foo este ucis de SIGPIPE, shell-ul va detecta acest lucru folosind una dintre funcțiile wait() și va imprima un mesaj „Broken pipe” sau similar.
Pe de altă parte, dacă foo moare primul, acesta este cazul obișnuit; închide capătul de scriere și apoi bar va ajunge pur și simplu la EOF și se va termina normal.
Răspuns
OpenConfig este o colecție de modele YANG standard pentru configurare și gestionare, care vor fi acceptate în mod nativ pe platformele hardware și software de rețea.
A devenit foarte costisitor pentru operatorii de rețea să își mențină cadrele automatizate pentru implementări cu mai mulți furnizori. >
Deși există multe interfețe de transport standard, nu există o reprezentare standard a datelor (Exemplu, furnizorul-A și furnizorul-B pot accepta interfețe standard (cum ar fi XML, REST, NETCONF …), dar cheia-valoare a datelor nu sunt aceleași. furnizorul-A ar putea reprezenta cheia interfeței ca „intf” și furnizorul-B ar putea reprezenta cheia interfeței ca „interfață”)
Deci, de fiecare dată când un operator de rețea adaugă / actualizează un nou dispozitiv în implementările lor de la diferiți furnizori, trebuie să își actualizeze cadrul automat și să scrie traducător pentru a converti specificațiile furnizorului reprezentarea datelor fic la reprezentarea datelor clienților.
Unii operatori de rețea precum Google, AT&T, BT, Microsoft … lucrează la împingerea acestor traducători către furnizor. Operatorilor nu le pasă cum obțin date, dar au nevoie de date în reprezentare comună, astfel încât instrumentele lor să poată înțelege și analiza datele cu ușurință.
Modelul YANG este utilizat pentru a defini aceste modele de date standard. Puteți consulta câteva modele standard de yang @ openconfig / public
YANG (încă o altă generație următoare) este un limbaj de definire a datelor.