Transportes

A transport es una interfaz del lado del cliente que puede conectarse a un URI de comms e intercambiar mensajes en tiempo real con pares o servicios.

Puedes ver el protocolo de comms en acción y experimentar con él usando el Comms Station.

Los clientes son libres de implementar transports como consideren (siempre que sigan el protocolo esperado por otros clientes y servicios), pero el diseño recomendado descrito a continuación ha sido probado en la práctica y ha demostrado integrarse bien con diferentes proyectos.`

Transports estándar

Hay 5 tipos de transport definidos por el protocolo:

• Websocket (ws-room) usa un flujo websocket estándar.

• LiveKit (livekit) utiliza el framework de código abierto LiveKit, basado en WebRTC.

• SignedLogin (signed-login) realiza una solicitud HTTPS firmada para obtener un transport asignado dinámicamente por un servidor.

• Offline (offline) es un transport ficticio que indica que no hay comms en el entorno actual.

• Simulator (simulator) es un transport ficticio con comportamiento completamente personalizado, principalmente para que los desarrolladores depuren sus implementaciones.

Los mensajes enviados y recibidos a través de una interfaz de transport siempre son los mismos (ver messages). Algunos transports pueden envolverlos en estructuras de control para la transmisión, pero estas deben desempaquetarse antes de cruzar la Transport interfaz.

Diseño recomendado

Esta es una Transport interfaz mínima escrita en TypeScript:

interface Transport {
  // Inicializar el Transport con un URI:
  constructor(private uriWithConnectionParams: string)

  // Abrir una conexión usando el URI pasado en el constructor:
  connect(): Promise<void>

  // Cerrar la conexión:
  disconnect(): Promise<void>

  // Enviar una carga arbitraria al servicio y a todos los pares:
  send(packet: Packet): Promise<void>

  // Suscribirse a mensajes entrantes tanto del servicio como de todos los pares:
  on(event: 'receive', callback: (packet: Packet) => void): void
}

Las implementaciones reales comúnmente extienden esto, añadiendo eventos de conexión/desconexión y unirse/abandonar, envío no broadcast, tipado más estricto o adaptaciones específicas del lenguaje.

URIs de Transport

Los valores de uriWithConnectionParams siempre tienen la forma:

<type>:<type connection parameters>

El <type> corresponde a uno listado arriba, y el formato para <type connection parameters> depende del transport específico. Puede ser una URL, un token opaco o cualquier dato arbitrario.

El LiveKit transport, por ejemplo, usa una wss URL con un access_token parámetro para establecer una conexión autenticada:

livekit:wss://comms.example.com?access_token=eyJhbGciOiJI...

Para comparar, el Websocket transport también usa una wss URL, pero sin un token pre-generado. Requiere un flujo de autenticación una vez conectado.

Creando Transports

Dado que cada Transport clase soportará un tipo particular de URI, es buena idea tener un método fábrica que devuelva un Transport válido o falle inmediatamente. Por ejemplo:

function createTransport(uriWithConnectionParams: string) {
  const type = getPrefix(urlWithConnectionParams)

  switch (type) {
    case 'ws-room': return new WsRoomTransport(uriWithConnectionParams)
    case 'livekit': return new LiveKitTransport(uriWithConnectionParams)
    // ... otras implementaciones soportadas ...
  }

  throw new Error(`Unsupported transport type: ${type}`)
}

No se requiere que los clientes implementen todos los transports estándar. Si pretenden usar solo un subconjunto de los tipos definidos sin intentar manejar todos los URIs, son libres de rechazar los tipos que no soportan.

Se aconseja a los clientes con más funciones, como un World Explorer, que implementen al menos los websocket y LiveKit transports, que actualmente son usados por todos los principales realms.

Aprende más

Dirígete a una sección de tipo de transport específica lee sobre los diferentes tipos de mensaje o consulta la [[Comms Demo Station]].