Esta es una traducción automática. El original en inglés está aquí: Update 20 October, 2022
Esta semana @joshuef trae algunas noticias sobre el progreso con comms (comunicaciones entre nodos). Como sabrán los lectores pacientes, esto ha sido un bloqueo por un tiempo, pero vemos una luz definitiva al final de este túnel en particular.
Actualización general
Un resumen rápido de lo que está haciendo el equipo.
@anselme ha estado investigando un ataque de clave no autorizada que afecta a otras implementaciones de BLS y ha descubierto que el nuestro también es vulnerable. Ha enviado una solución a la caja blsttc. También está investigando un error que impide que los clientes se unan a la red en las pruebas.
@chriso está trabajando en la firma de fragmentos y registros, que es donde los datos (o su Xorname en el caso de fragmentos) son firmados por los ancianos para que sean válidos en la red.
En relación con esto, @bochaco está realizando cambios en la API del cliente relacionados con comandos y fragmentos, y está depurando errores relacionados con ellos en CI.
Mostafa está ocupado en casos de prueba para nuestro mecanismo de consenso, y @bzee continúa investigando qp2p, donde creemos que hay una falla profundamente arraigada que afecta la conectividad.
Progreso de las comunicaciones
Entonces, algo en lo que estamos trabajando es en eliminar nuestro código de reducción de conexión y simplemente confiar en el código quinn subyacente para eliminar las conexiones después de un tiempo de espera más pequeño. De esta manera, estamos suponiendo menos y ya no dudamos más de lo que está abierto y cuándo.
En nuestras pruebas, esto ha tenido un impacto positivo en las pruebas de los clientes, eliminando la probabilidad de que nuestras conexiones se cierren a la mitad.
Transmisiones bisexuales
Paralelamente, también nos estamos moviendo para agilizar las comunicaciones de cliente/nodo mediante flujos bidireccionales. Esto significa que eliminamos parte de la complejidad de la gestión del estado y solo esperaremos una respuesta de los mayores. Anteriormente (hace mucho tiempo en el mundo de los nodos), usábamos este tipo de flujos para comunicarnos con los clientes, pero administrar el flujo de respuesta era una pesadilla complicada. Pero ahora el nodo es mucho más sencillo (debido al trabajo realizado durante el último año y medio más o menos), y esto es mucho más manejable.
Reintentos reducidos
También buscamos eliminar cualquier cosa que haya estado encubriendo estos problemas (como nuestras abstracciones de comunicaciones como se mencionó anteriormente), y también los reintentos de la capa del cliente. Ahora tenemos mensajes ACK (acuse de recibo) (se introdujeron hace unos meses), para el cliente. Estos ayudan a decirnos cuándo los ancianos han visto un comando. Pero todavía estábamos consultando hasta que se devolvió un fragmento. @bochaco ha estado buscando ser más estricto aquí… no permitir reintentos y simplemente decir “hemos visto el ‘ACK’… entonces, ¿por qué no estamos viendo el éxito la primera vez?”. Esto ha expuesto algunos errores en la lectura/escritura de archivos. (Parece que deserializar los comandos de almacenamiento puede tomar más que las consultas… así que incluso si se envían después, los estamos procesando primero).
Cargas de procesamiento de nodos reducidas
En un esfuerzo por regular de manera más adecuada el manejo de comandos de nodos, previamente agregamos código que debería haber estado organizando los mensajes entrantes y ordenándolos para su procesamiento. De hecho, hemos visto que esto no estaba teniendo el impacto que buscábamos en absoluto (de hecho, simplemente provocó que todos los mensajes se procesaran uno tras otro, independientemente de la prioridad).
Eliminar este código ha permitido una gran simplificación de nodos. Lo que es más importante, hemos podido mover el manejo de procesos de nodos fuera del subproceso sin bloqueos (después de que nuestro impulso de un solo subproceso eliminó la gran mayoría del código de bloqueo).
Impacto
Anteriormente, podíamos rastrear los mensajes que ingresaban, se ponían en cola para su procesamiento, se manejaban y luego se ponían en cola para enviar. Este proceso bajo carga podría llevar un tiempo considerable. A veces era relativamente rápido, sub segundo. A veces, con todo el procesamiento de comandos y mensajería IO… podría tardar 20 segundos.
Ahora estamos viendo mensajes que ingresan de manera rutinaria a los nodos, se procesan de inmediato y los mensajes se envían en submilisegundos.
Esto está mucho más cerca de lo que hubiéramos esperado de nuestras comunicaciones anteriormente, y se siente como la dirección correcta.
Próximos pasos
Estamos buscando incorporar completamente las secuencias bidireccionales en los clientes, eliminando una gran cantidad de gestión estatal allí. Y también intentaremos tener este mismo flujo en las comunicaciones entre adultos mayores y mayores donde se requieren respuestas, lo que debería simplificar aún más las cosas allí también. En realidad, debería permitir que nuestros mensajes ACK también reflejen el almacenamiento de adultos, en lugar de que solo los ancianos digan que han visto un mensaje, lo que también debería ayudar con las verificaciones fallidas.
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
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.