> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-pt/comunicacoes/transports.md).

# Transportes

A *transporte* é uma interface do lado do cliente que pode se conectar a uma URI de comms e trocar mensagens em tempo real com pares ou serviços.

{% hint style="info" %}
Você pode ver o protocolo comms em ação e experimentá-lo usando o código aberto [Comms Station](https://decentraland.github.io/comms-station/).
{% endhint %}

Os clientes são livres para implementar transportes como acharem adequado (desde que sigam o protocolo esperado por outros clientes e serviços), mas o [design recomendado](#recommended) descrito abaixo foi testado na prática e comprovou integrar-se bem com diferentes projetos.\`

### Transportes padrão <a href="#types" id="types"></a>

Há 5 tipos de transporte definidos pelo protocolo:

* [WebSocket](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/websocket/README.md) (`ws-room`) usa um fluxo WebSocket padrão.
* [LiveKit](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/livekit/README.md) (`livekit`) usa o framework LiveKit de código aberto, baseado em WebRTC.
* [SignedLogin](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/signed_login/README.md) (`signed-login`) faz uma solicitação HTTPS assinada para obter um transporte atribuído dinamicamente de um servidor.
* [Offline](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/offline/README.md) (`offline`) é um transporte fictício e indica que não há comms no ambiente atual.
* [Simulador](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/simulator/README.md) (`simulador`) é um transporte fictício com comportamento completamente personalizado, principalmente para desenvolvedores depurarem suas implementações.

As mensagens enviadas e recebidas por meio de uma interface de transporte são sempre as mesmas (veja [mensagens](https://github.com/decentraland/docs/tree/main/contributor/communications/messages/README.md)). Alguns transportes podem encapsulá-las em estruturas de controle para transmissão, mas estas devem ser descompactadas antes de atravessar a `Transport` interface.

### Design recomendado <a href="#recommended" id="recommended"></a>

Esta é uma `Transport` interface mínima escrita em TypeScript:

```ts
interface Transport {
  // Inicialize o Transport com uma URI:
  constructor(private uriWithConnectionParams: string)

  // Abra uma conexão usando a URI fornecida no construtor:
  connect(): Promise<void>

  // Feche a conexão:
  disconnect(): Promise<void>

  // Envie um payload arbitrário para o serviço e todos os pares:
  send(packet: Packet): Promise<void>

  // Inscreva-se para receber mensagens recebidas tanto do serviço quanto de todos os pares:
  on(event: 'receive', callback: (packet: Packet) => void): void
}
```

As implementações reais geralmente estendem isto, adicionando eventos de conexão/desconexão e entrada/saída, envio sem broadcast, tipagem mais rígida ou adaptações específicas da linguagem.

#### URIs de transporte

Os valores de `uriWithConnectionParams` são sempre da forma:

```
<type>:<type connection parameters>
```

O `<type>` corresponde a um dos listados acima, e o formato de `<type connection parameters>` depende do transporte específico. Pode ser uma URL, um token opaco ou quaisquer dados arbitrários.

O [LiveKit](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/livekit/README.md) transporte, por exemplo, usa uma `wss` URL com um `access_token` parâmetro para estabelecer uma conexão autenticada:

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

Para comparação, o [WebSocket](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/websocket/README.md) transporte também usa uma `wss` URL, mas sem um token pré-gerado. Requer um fluxo de autenticação uma vez conectado.

#### Criando Transportes

Como cada `Transport` classe suportará um tipo específico de URI, é uma boa ideia ter um método de fábrica que ou retorna um válido `Transport` ou falha imediatamente. Por exemplo:

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

  switch (type) {
    case 'ws-room': return new WsRoomTransport(uriWithConnectionParams)
    case 'livekit': return new LiveKitTransport(uriWithConnectionParams)
    // ... outras implementações suportadas...
  }

  throw new Error(`Tipo de transporte não suportado: ${type}`)
}
```

Os clientes não são obrigados a implementar todos os transportes padrão. Se pretendem usar apenas um subconjunto dos tipos definidos sem tentar lidar com todas as URIs, são livres para rejeitar os tipos que não suportam.

Clientes mais completos, como um World Explorer, são aconselhados a implementar pelo menos o [WebSocket](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/websocket/README.md) e [LiveKit](https://github.com/decentraland/docs/tree/main/contributor/communications/transport-types/livekit/README.md) transportes, que estão atualmente em uso por todos os principais realms.

### Saiba mais

Acesse uma [seção de tipo de transporte específico](#types) seção, leia sobre os diferentes [tipos de mensagem](https://github.com/decentraland/docs/tree/main/contributor/communications/messages/README.md) ou confira o \[\[Comms Demo Station]].


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/contributor/contributor-pt/comunicacoes/transports.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.