Cómo funciona una transferencia de navegador a navegador

La forma más clara de entender Mándamele es separar el plano de control del plano de datos. El plano de control crea el Pase, incorpora al segundo navegador, mantiene el estado y transporta los mensajes técnicos de WebRTC. Funciona mediante WebSocket y un Durable Object asociado al código. Este componente sabe qué dos conexiones pertenecen al mismo Pase, pero no recibe el texto ni los fragmentos de archivo.

El plano de datos empieza cuando los navegadores consiguen abrir un RTCDataChannel. Desde ese momento, los mensajes de texto y los archivos se envían por ese canal. El código del cliente no ofrece una ruta alternativa que copie el contenido al WebSocket. Si la conexión directa falla, el producto muestra un error; no cambia silenciosamente a una subida al servidor.

Al pulsar «Enviar algo», el navegador abre un WebSocket al endpoint de creación. El Worker genera un código de seis caracteres con un alfabeto de 31 símbolos que evita varios caracteres ambiguos. En entornos con Web Crypto disponible, la generación usa valores aleatorios criptográficos y descarta valores que introducirían sesgo al elegir un símbolo.

El Durable Object registra el estado necesario para la conexión: código, participantes, momentos de creación y actividad, y conexiones WebSocket. Un Pase anónimo todavía no conectado caduca a los diez minutos. El servidor devuelve el código al primer navegador, que también crea un enlace y un QR con ese mismo dato.

El segundo navegador normaliza el código, abre su WebSocket y solicita entrar. En esta configuración de pruebas y en el flujo actual, la aprobación manual está desactivada y el primer navegador aprueba automáticamente la solicitud válida. La arquitectura conserva los eventos de aprobar y rechazar, pero la interfaz pública no hace esperar al usuario en este pase de QA.

Una vez asociados, ambos lados reciben el identificador técnico del otro participante. Esos identificadores permiten dirigir ofertas, respuestas y candidatos ICE al navegador correcto. Son datos de control. Todavía no se ha enviado ningún archivo y el hecho de conocer el código no proporciona una copia de contenidos anteriores, porque el servicio no mantiene un historial de transferencias.

El navegador que creó el Pase construye un RTCPeerConnection y un DataChannel llamado «mandamele», configurado como ordenado. Genera una oferta SDP y la envía por el WebSocket. El otro navegador establece esa oferta como descripción remota, crea una respuesta y la devuelve por el mismo plano de control. Ambos reenvían también candidatos ICE a medida que aparecen.

La configuración incluye stun:stun.l.google.com:19302 para ayudar a descubrir direcciones utilizables. No incluye TURN. Si los cortafuegos, NAT, VPN o políticas del navegador no permiten una ruta entre ambos extremos, la negociación puede quedar bloqueada o fallar. Después de una caída, el propietario intenta reiniciar ICE y espera ocho segundos antes de tratar la recuperación como fallida.

Cada lado anuncia que su DataChannel está preparado. Cuando el canal local está abierto y el remoto ha confirmado disponibilidad, la interfaz habilita los controles. Un texto se serializa como mensaje de control del propio DataChannel. Un archivo empieza con metadatos validados —nombre, tipo, tamaño, fragmentos— y continúa con bloques binarios de 64 KiB en orden.

El emisor espera cuando bufferedAmount supera 1 MiB y reanuda al bajar del umbral configurado de 512 KiB. Esto es control de presión, no almacenamiento remoto. El receptor suma los fragmentos, comprueba el tamaño esperado y crea un Blob local. Los archivos de más de 50 MB se rechazan antes de iniciar el envío.

Mientras un Pase está conectado, el cliente envía un ping de control cada 25 segundos. Para los Pases anónimos, treinta minutos sin actividad cierran la sesión. Cerrar una pestaña o abandonar el Pase desconecta al otro navegador. Estos plazos se refieren al estado de conexión, no a una política de conservación de archivos en servidor, porque el contenido no se sube allí.

La palabra «directo» describe la ruta implementada para el contenido, no una garantía de que cualquier combinación de redes vaya a conectar, de velocidad concreta o de ausencia de copias locales. El rendimiento depende de ambos dispositivos y redes. El receptor decide si descarga, copia o conserva lo recibido, y cada usuario debe verificar el archivo antes de depender de él.