Actualización de Safe Network Dev 🇪🇸 7 julio 2022

Esta es una traducción automática. El original en inglés está aquí: Update 7 July, 2022

Crédito a Spatium por las 4 imágenes de título que verá en las próximas semanas :heart_eyes:

Algunas noticias prometedoras en el frente de la búsqueda de errores, ya que el equipo ha rastreado una pequeña criatura desagradable que estaba causando puntos muertos durante la replicación de datos en el abandono. Para los técnicos, el error en cuestión era una referencia a un nodo de lectura bloqueada que persistía incluso después de que se había descartado, y el trabajo en curso para eliminar los subprocesos múltiples y simplificar el código hizo posible rastrearlo. Como tal, pensamos que sería un buen momento para poner al día a la gente sobre el trabajo que estamos haciendo en sn_node en este y otros aspectos. @joshuef toma los mandos esta semana.

Progreso general

@yogesh está listo para refactorizar la base de código para deshacerse de SledDB. Como se mencionó en las actualizaciones anteriores, estábamos en camino de reemplazar SledDB (para almacenar registros) ya que tenía problemas de limitaciones de escritura y tampoco se mantenía activamente. Por lo tanto, evaluamos algunas alternativas en las semanas anteriores, donde cada una tenía sus pros y sus contras. Como resultado del análisis, el equipo decidió optar por la implementación interna de almacenamiento en disco que ya empleamos para almacenar fragmentos. Esta es una implementación de keep-it-simple que no tiene adornos y silbatos y funciona a la par con las otras alternativas, mientras que esto también nos libera de tener otra dependencia externa que podría no estar súper mantenida. Actualmente, solo admite el almacenamiento de fragmentos y, por lo tanto, debe renovarse para admitir el almacenamiento de registros, para lo cual el trabajo está en marcha.

@qi_ma ha estado observando las pruebas de abandono que han fallado y han sido lentas, en parte, creemos, debido al error descrito en la introducción (y más abajo). También se han enviado mensajes falsos a los clientes, que bien podrían ser parte del mismo problema.

También esta semana, @Heather_Burns hizo un regreso triunfal después de la plaga al Parlamento del Reino Unido, donde representó a MaidSafe en una mesa redonda de pequeñas empresas tecnológicas y nuevas empresas que pueden ser daños colaterales en la determinación del gobierno de regular Internet en torno a Facebook. Heather informa que los parlamentarios con los que se reunió son algunos de los pocos que realmente ‘entienden esto’ y quieren evitar que eso suceda, por lo que esperamos que nuestro mensaje se escuche alto y claro. Sin darse cuenta, ella también puede haber destruido el gobierno. ¡Vaya!

Estado del Nodo

Muchas personas pueden preguntarse cuál es el estado del nodo ahora y por qué hemos estado asumiendo ciertas tareas.

Aquí hay un pequeño resumen del estado de los nodos:

Menos bloqueos

En las últimas semanas, movimos el nodo a una configuración de subproceso único. Aparentemente, esto no ha tenido mucho impacto en el rendimiento (aunque mejoró un poco las cosas), pero el objetivo aquí era simplificar la base del código. Con solo un hilo del que preocuparnos (de forma predeterminada… aún podemos generar otros según sea necesario), no necesitamos tener tantos controles y equilibrios en todo el código para permitir que funcione de manera concurrente.

El ejemplo más claro de esto es la capacidad de eliminar RwLocks (bloqueos de lectura y escritura) del código base. Estas pequeñas estructuras permiten que el código espere hasta que un dato determinado no se modifique en otro subproceso, antes de que lo editemos. ¡Pulcro!. Sí. Pero también peligroso. Muchos de los errores y problemas recientes que hemos solucionado en sn_node se han producido debido a estas esperas indefinidas (una situación a la que nos referimos como interbloqueo).

Es aquí donde realmente brilla el paso a sn_node de subproceso único, ya que podemos eliminar la gran mayoría de estos del código base, y con ellos, eliminamos una clase completa de errores (¡y también es realmente doloroso depurar errores!). Por lo tanto, el código no solo es más limpio, más claro y más sensato, ¡sino que debería ser menos propenso a errores al arrancar!

Estamos ~ 80% del camino a través de esto ahora. Habiendo eliminado muchos bloqueos sobre las estructuras internas de nodos, y reemplazándolos con un bloqueo de nivel superior, es mucho más fácil razonar (¡aunque la transición resultó en otro punto muerto!). Un buen ejemplo de las mejoras en la simplicidad que se traducen en velocidad se puede ver en algunos de nuestros Benchmarks.

Esta es una gran victoria.

Redes de prueba

Otra área en la que hemos estado trabajando para mejorar las cosas, y continuaremos haciéndolo, es en las redes de prueba y la depuración. Algunos errores de testnet han sido el resultado de fallas en la infraestructura, por ejemplo, digamos que comenzamos una gota de DigitalOcean, pero el nodo no se inició correctamente allí por algún motivo. Los cambios recientes han hecho que los reinicios de nodos sean más estables, así como la limpieza del código de bucle en segundo plano, lo que debería ayudar en situaciones como esta.

También buscamos mejorar la situación del registro, con algunos registros Cmd más claros que se generarán por separado de los registros de ejecución más detallados. Estos deberían ser más fáciles de analizar para la gente y, con suerte, podremos conectarlos a la instancia de ElasticSearch que tenemos para las redes de prueba internas.

Afiliación

El número de miembros sigue mejorando, aunque se ha retrasado con el singleinterruptor roscado. Buscamos cerrar la brecha entre lo que los nodos entienden y votan, y lo que se comparte dentro de un SectionAuthorityProvider (SAP). Esto también debería mejorar la estabilidad.

Disfunción

Otra clase de errores que ahora estamos abordando es una clase de errores algo más ‘meta’: los nodos votan a otros nodos como disfuncionales (y, por lo tanto, fuera de línea). Hacer esto bien es complicado (¿cuándo un nodo es disfuncional frente a tener un mal momento temporal?). Ese dolor se siente de manera aguda en la integración continua (CI), donde las máquinas son menos poderosas, por lo que a veces podemos ver nodos que se votan fuera de línea, lo que puede romper un ciclo de prueba…

Con ese fin, recientemente ampliamos las suites de prueba en sn_dysfunction y estamos buscando seguir expandiendo y mejorando esto, para llegar a situaciones reproducibles en las que podamos saber que los votos fuera de línea se producen debido a nodos defectuosos.

Memoria y CPU

Con los cambios de un solo subproceso, la reciente reelaboración de la republicación de datos, y con algunas simplificaciones en el código base del nodo sn_node generalmente funciona muy bien, con un promedio de uso de memoria de ~130 MB para un anciano (en una Mac; red de prueba local), ~70 MB para adultos

En este momento, cualquier pico grande es una bandera roja clara para nosotros, y ese es un lugar realmente agradable para estar, ya que hace que encontrar la causa de tales problemas sea mucho más fácil de detectar.

Datos

El reciente descubrimiento de errores de “trineo” ha frenado la sensación de estabilidad en los datos, pero estamos trabajando para eliminar eso ahora mismo. Con suerte, este cambio debería simplificar y unificar el almacenamiento de datos en sn_node, por lo que el comportamiento debería ser más consistente en cualquier tipo de datos.

Y muuuuuuuuuuuuuuuuuuuu…

Si bien es posible que no siempre se sienta que las cosas están progresando para la comunidad dado que no todos ven en qué se está trabajando y mejorando día a día, las cosas definitivamente van en la dirección correcta. Cada red de prueba que activamos es más estable (en general), pero si por alguna razón hay un error, con todos estos cambios recientes, además de las estadísticas de las gotas de seguimiento del servidor ElasticSearch, se vuelve mucho más fácil ver dónde están los problemas y ¡Esperemos que solo sea cada vez más fácil también!


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.