Actualizaci贸n de Safe Network Dev 馃嚜馃嚫 14 de enero de 2021

Esta es una traducci贸n autom谩tica. El original en ingl茅s est谩 aqu铆: Safe Network Dev Update - January 14, 2021

Resumen

Estas son algunas de las cosas principales a destacar desde la 煤ltima actualizaci贸n de desarrollo:

  • Seguimos moviendo todas las definiciones de mensajes del cliente y la l贸gica de serializaci贸n a la nueva caja de sn_messaging.
  • Trabajar para eliminar la administraci贸n de stream en los nodos, como se mencion贸 en la actualizaci贸n de la semana pasada, se ha completado y combinado
  • Hemos estado trabajando y solucionando los problemas destacados por nuestra nueva herramienta de prueba de estr茅s de enrutamiento.
  • Un saludo masivo y gracias a un par de miembros de la comunidad por las relaciones p煤blicas de esta semana: @mav y @tfa contribuyeron con m煤ltiples relaciones p煤blicas en diferentes repositorios para ayudar y mejorar nuestro trabajo. Siempre inspirador ver :heartbeat:
  • Todav铆a estamos trabajando para probar una resoluci贸n de error final que esperamos signifique que podamos lanzar la pr贸xima iteraci贸n de la red de prueba.

Cliente seguro, nodos y qp2p

Plan del proyecto Safe Network Transfers
Plan de proyecto de cliente seguro
Plan de proyecto de nodo de red segura

Durante la 煤ltima semana, dedicamos m谩s tiempo a mejorar los ejemplos de qp2p para que demuestren mejor las caracter铆sticas de la biblioteca por separado. Junto con esto, ampliamos el ejemplo del servicio de eco para admitir el reenv铆o de puertos manual. Al implementar esto, identificamos e implementamos una peque帽a extensi贸n que verificaba el punto final proporcionado por el usuario como entrada. Esto nos permite devolver un error mucho antes en lugar de esperar a que la red identifique y notifique el nodo como inalcanzable.

Tambi茅n continuamos moviendo todas las definiciones de mensajes de cliente y la l贸gica de serializaci贸n a la nueva caja de sn_messaging. Hemos mejorado el protocolo y ahora estamos usando Msgpack para serializar todos los mensajes que env铆an los clientes a los nodos. Sin embargo, esta es una tarea en curso, ya que algunas partes internas de los mensajes del cliente todav铆a est谩n usando la serializaci贸n de bincode y, por lo tanto, debemos migrarlas para usar tambi茅n Msgpack.

El trabajo ha continuado con las transiciones de actores distribuidos en el cambio de ancianos, es decir, firmando los fondos de la secci贸n a las nuevas constelaciones de ancianos. Un peque帽o error que obstaculiza la transici贸n (debido a una falla en la validaci贸n de la firma) ha tardado alg煤n tiempo en eliminarse, pero acaba de ser encontrado. Ahora se van a probar los pr贸ximos pasos de la transici贸n.

Por 煤ltimo, hemos estado avanzando con la actualizaci贸n del cliente / nodo para eliminar los desaf铆os del cliente y para volver a habilitar la incorporaci贸n * adecuada * de los clientes, despu茅s del trabajo para eliminar la administraci贸n de stream en los nodos, como se menciona en la actualizaci贸n de la semana pasada, se complet贸 y fusion贸. Esto, a su vez, ha generado algunos problemas potenciales en la recepci贸n o el an谩lisis de mensajes del cliente, por lo que estamos investigando.

API y CLI

Esta semana pudimos generar con 茅xito compilaciones musl para CLI y authd en nuestro CI y, por lo tanto, todo est谩 configurado y listo para nuestra pr贸xima versi贸n. Esto significa que tanto la CLI como las aplicaciones authd deben ser compatibles con cualquier plataforma Linux lista para usar en el paquete de lanzamiento, necesitaremos que la comunidad nos ayude a validar que este es realmente el caso prob谩ndolo en tantas plataformas Linux diferentes como sea posible. Lanzaremos las nuevas versiones a su debido tiempo.

BRB - Difusi贸n confiable bizantina

El trabajo continu贸 esta semana para pulir a煤n m谩s las cajas de BRB. La API de tipo de datos se modific贸 para que los detalles del error de validaci贸n puedan devolverse a la persona que llama. Adem谩s, en este sentido, la caja rust-crdt se ha mejorado de modo que cada tipo de CRDT que utilizamos ahora tiene un m茅todo validate () que se puede llamar antes de aplicar una operaci贸n. Se han realizado solicitudes de extracci贸n para CI / CD (integraci贸n continua y despliegue y entrega continuos) para cada caja de BRB. Tenemos algunos cambios m谩s para terminar esta semana, despu茅s de lo cual planeamos hacer el primer lanzamiento en crates.io.

Enrutamiento

Plan del proyecto

La semana pasada mencionamos c贸mo la herramienta de prueba de esfuerzo descubri贸 algunos problemas ocultos en el enrutamiento. Esta semana nos propusimos rastrearlos y arreglarlos. Un problema fue que los miembros no mayores de una secci贸n no sabr铆an que se produjo una divisi贸n debido a un error en c贸mo se crearon los mensajes Sync. Esto se solucion贸 y se fusion贸. Hay otro PR actualmente en progreso que soluciona un par m谩s de esos problemas. Los problemas restantes despu茅s de eso probablemente est茅n todos relacionados con la forma en que manejamos los cambios de membres铆a de la secci贸n. Esperamos resolverlos integrando el nuevo algoritmo de membres铆a de BRB que tambi茅n se mencion贸 la semana pasada. Este trabajo comenzar谩 muy pronto, posiblementetan pronto como la semana que viene, si todo va bien.

De manera similar a nuestro movimiento reciente para tener todas las definiciones de mensajes del cliente y la l贸gica de serializaci贸n en una caja separada (sn_messaging), comenzamos a buscar hacer lo mismo con los mensajes sn_routing. El objetivo es poder separar toda la definici贸n de mensajes y la l贸gica de serializaci贸n, de la l贸gica de enrutamiento central. Esto deber铆a permitirnos tener una definici贸n clara de la interfaz expuesta por los servicios de enrutamiento y, por lo tanto, c贸mo cualquier implementaci贸n (en cualquier lenguaje de programaci贸n) puede hacerse compatible con nuestra implementaci贸n sn_routing existente. Estamos en las primeras etapas de este proceso, pero quer铆amos compartir nuestro objetivo aqu铆.

Enlaces 煤tiles


No dude en responder a continuaci贸n con enlaces a las traducciones de esta actualizaci贸n para desarrolladores y los moderadores las agregar谩n aqu铆.

Como proyecto de c贸digo abierto, siempre estamos buscando retroalimentaci贸n, comentarios y contribuciones de la comunidad, as铆 que no sea t铆mido, 煤nase y creemos la red segura juntos.