Byte runtime

Implementado en parte. El nodo track/byte-runtime sigue en curso. Lo que sigue describe lo que existe en native/zig/ y marca lo que sólo está propuesto. El estado de cada gate es el de la vista generada del roadmap.

El byte runtime es la parte del daemon que lleva los bytes de un fichero (o de un fragmento empaquetado) hasta el cliente sin pasar por JavaScript. Su arquitectura se eligió en la decisión r44 (Candidate H) y se reancló sobre las primitivas compartidas de zkit en dec-0103.

Las piezasCopiar enlace

Caché por nivelesCopiar enlace

Tres niveles con política propia (decisión r45):

• L1, RAM: dominada por recencia; contabilidad de coste constante, camino de nanosegundos.
• L2, NVMe: dominada por coste de regeneración, con recencia como desempate. Un transcode caro no se tira para hacer sitio a un original que se relee en milisegundos; un elemento caro pero frío no bloquea indefinidamente.
• L3, SFTP: por caducidad o manual, sin expulsión bajo presión.

El almacenamiento remoto va por API nativa, nunca por FUSE en el camino caliente.

Presupuestos y contrapresiónCopiar enlace

Todo recurso tiene un presupuesto anidado: daemon, actor, sesión, conexión. Agotarlo falla la sesión, no el daemon (dec-0117 I4). Los puntos que lo hacen cumplir:

• La memoria por sesión pasa por un asignador con presupuesto de zkit.safety.
• La ruta de envío de bytes por WebTransport y HTTP/3 está pautada y limitada por los bytes aún no confirmados por el par.
• Las listas de reproducción y el segmento de inicialización también pasan por el presupuesto de envío y por topes de peticiones en vuelo, en vez de enviarse enteros desde el hilo del bucle.
• La admisión (conexiones, flujos, sesiones por actor) sigue a la capacidad: la tabla de conexiones tiene topes por dirección y por actor, y una conexión sin capacidad aceptada tiene un plazo corto.

Políticas de cola de MoQTCopiar enlace

La entrega por MoQT distingue dos perfiles (dec-0104, enmendado por dec-0122):

• VOD: nunca descarta. La contrapresión es por suscriptor, con un trasiego propio acotado, y el que no sigue el ritmo se corta con un error de carga excesiva y retoma con FETCH. No retiene la pista ni la cola compartida. Hay cuota por pista.
• Directo: conserva el descarte del más antiguo.

Qué sólo está propuestoCopiar enlace

• ExtentMap y la disponibilidad parcial de un asset.
• Producción fuera del bucle QUIC.

Son ADRs propuestos: mientras no se lockeen, no son parte del contrato del byte runtime. El discriminante entre directo y VOD en el dominio (dec-0107) sí está LOCKED desde el 2026-10-01.

Primitivas compartidasCopiar enlace

El byte runtime consume zkit y no reimplementa nada de lo genérico (dec-0103): relojes, locks, ficheros, cola acotada, cola de prioridad, losa de handles generacionales, búfer de copia cero, token de cancelación, asignador con presupuesto y lectores acotados de los parsers vienen de ahí. Una guarda de construcción lo impide (zig build audit:safety, bun run check:zkit-no-reimpl). Hay primitivas de zkit que styx no consume porque no tienen carga de trabajo real que las use (la cola de suscriptores, el búfer de reordenación o el vigilante de trabajadores): no se cablean hasta que la tengan. Detalle en zkit, spire y conduit.