Mejor respuesta
SIGPIPE es la señal de «tubería rota», que se envía a un proceso cuando intenta escribir en una tubería cuyo extremo de lectura tiene cerrado (o cuando intenta escribir en un socket que ya no está abierto para lectura), pero no viceversa . La acción predeterminada es terminar el proceso.
Este comportamiento es útil para casos típicos de procesos en ejecución en canalizaciones. Si ejecuta foo | bar, nunca podrá ver la salida de foo directamente; se convierte en la entrada para bar y verá el resultado de bar. Esto significa que si, por ejemplo, bar muere, entonces no tiene sentido que foo continúe produciendo resultados. Esto puede suceder porque bar ha fallado o porque ya no necesita entrada (por ejemplo, si está escaneando su entrada para asegurarse de que no haya errores, puede detenerse después de encontrar el primero).
Imagínese lo que sucedería si SIGPIPE no existiera y bar muriera (ya sea debido a un error o simplemente porque decidió salir ). foo continuaría ejecutándose y tendría que recibir un código de error al intentar escribir. Podría ignorar esto y continuar ejecutándose, dejando al usuario sin ninguna indicación obvia de que se ha producido la condición posiblemente anormal de bar terminando primero. Cuando foo es eliminado por SIGPIPE, el shell lo detectará usando una de las funciones wait() e imprimirá un mensaje «Tubería rota» o similar.
Por otro lado, si foo muere primero, este es el caso habitual; cierra el final de escritura, y luego bar simplemente alcanzará el EOF y terminará normalmente.
Respuesta
OpenConfig es una colección de modelos YANG estándar de la industria para configuración y administración que serán compatibles de forma nativa en plataformas de hardware y software de red.
Se ha vuelto muy costoso para los operadores de red mantener sus marcos automatizados para implementaciones de múltiples proveedores.
Aunque hay muchas interfaces de transporte estándar, no hay una representación de datos estándar (por ejemplo, el proveedor A y el proveedor B pueden admitir interfaces estándar (como XML, REST, NETCONF …), pero los datos clave-valor no son los mismos. vendor-A podría representar la clave de interfaz como «intf» y vendor-B podría representar la clave de interfaz como «interface»)
Así que cada vez que un operador de red agrega / actualiza una nueva dispositivo en sus implementaciones de diferentes proveedores, necesitan actualizar su marco automatizado y escribir traductor para convertir la especificación del proveedor representación de datos fic a representación de datos de clientes.
Algunos operadores de red como Google, AT&T, BT, Microsoft … están trabajando para llevar estos traductores al proveedor. A los operadores no les importa cómo obtienen los datos, pero necesitan datos en una representación común para que sus herramientas puedan comprender y analizar los datos fácilmente.
El modelo YANG se está utilizando para definir estos modelos de datos estándar. Puede ver algunos modelos estándar de yang @ openconfig / public
YANG (Yet Another Next Generation) es un lenguaje de definición de datos.