> 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-es/comunicaciones/overview.md).

# Resumen

El sistema de comunicaciones de Decentraland, o simplemente *comms*, es el protocolo de mensajería en tiempo real que gestiona la interacción entre jugadores en un Realm.

Algunas de estas interacciones son iniciadas por los jugadores; otras son gestionadas automáticamente por los clients bajo el capó. Algunos ejemplos:

* Chat de texto y de voz
* Actualizaciones de posición a medida que los jugadores se desplazan
* Actualizaciones del avatar cuando los jugadores cambian su apariencia

{% hint style="info" %}
Puedes ver el protocolo de comms en acción y experimentarlo usando el código abierto [Comms Station](https://decentraland.github.io/comms-station/).
{% endhint %}

Dado que la mayor parte de esta funcionalidad requiere difundir mensajes a todos los jugadores cercanos, se agrupan automáticamente en clústeres basados en proximidad llamados *islas*. A cada jugador se le asigna una sola isla a la vez, lo que cambia a medida que viajan por el mundo y se mueven en relación con los demás.

El servicio de Realm que gestiona y asigna jugadores a las islas se llama *Archipelago*. Se encarga de crear islas según se necesiten, mantener su población en un número razonable y reasignar dinámicamente a los jugadores en respuesta a sus movimientos.

```mermaid
flowchart LR
    subgraph Realm
        Players["Jugadores<br/>⭐⭐⭐⭐⭐⭐⭐⭐⭐"]
        Archipelago["Archipelago"]
        
        subgraph Islas
            Island1["Isla 1<br/>⭐⭐⭐⭐"]
            Island2["Isla 2<br/>⭐⭐⚪⚪"]
            IslandN["Isla n<br/>⭐⭐⭐⚪"]
        end
        
        Players --> Archipelago
        Archipelago --> Island1
        Archipelago --> Island2
        Archipelago --> IslandN
    end
```

Cuando se asigna a un cliente a una isla, se le proporciona un URI específico de la isla para conectarse al backend real que retransmitirá mensajes entre ellos. Esta conexión dura hasta que Archipelago reasigna al cliente a una isla diferente.

Esto significa que, además del [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) protocolo, los clientes deben implementar una serie de *transportes*, cada uno encapsulando uno de los backends compatibles en una interfaz unificada.

### Ciclo de vida del cliente <a href="#lifecycle" id="lifecycle"></a>

El ciclo de vida de un cliente de comms puede resumirse en unos pocos pasos:

1. **Seleccionar un Realm**: obtener un URI para el [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) servicio.
2. **Unirse a Archipelago**: abrir una conexión persistente con el servicio.
3. **Obtener una reasignación de isla**: informar de la posición actual y obtener un URI específico de la isla.
4. **Conectar un transporte**: abrir una segunda conexión al backend específico de la isla.
5. **Repetir**: seguir con los pasos 3 y 4, informando periódicamente de nuevas posiciones.

Cuando el cliente finaliza su sesión, simplemente se desconecta del servicio Archipelago. Será eliminado automáticamente de su isla actual.

```mermaid
sequenceDiagram
    participant Archipelago
    participant Client
    participant IslandBackend as Backend de la isla
    
    Note over Client: Conectarse a Archipelago
    Client->>Archipelago: Autenticar
    Archipelago->>Client: Aceptar
    
    Note over Client: Informar posición
    Client->>Archipelago: Informar posición
    Archipelago->>Client: Asignar isla
    
    Note over Client: Conectarse a la isla
    Client->>IslandBackend: Conectar transporte
    Client->>IslandBackend: Autenticar
    IslandBackend->>Client: Aceptar
    
    Note over Client,IslandBackend: Intercambiar mensajes
    Client->>IslandBackend: Mensajes de jugadores…
    IslandBackend->>Client: Mensajes de jugadores…
    
    Note over Client: Actualizar posición
    Client->>Archipelago: Actualizar posición
    Archipelago->>Client: Reasignar isla
    
    Note over Client: Desconectarse de la isla anterior
    Client->>IslandBackend: Desconectar transporte
    
    Note over Archipelago,IslandBackend: Repetir ciclo
```

### Conexiones

Las conexiones de comms se basan principalmente en WebSocket, aunque algunos transportes pueden usar otras estrategias.

Ve a la [Transportes](https://github.com/decentraland/docs/tree/main/contributor/communications/transports/README.md) o [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) secciones para saber más, o una página de transporte específica para más detalles al respecto.

### Autenticación

Las conexiones a comms se autentican haciendo que los clientes firmen un desafío proporcionado por el servidor, usando el esquema descrito en el [cadena de autenticación](https://github.com/decentraland/docs/tree/main/contributor/auth/authchain/README.md) sección.

Dirígete a la [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) página o consulta un transporte específico para saber más sobre los flujos de autenticación.

### Islands

Las islas son grupos de jugadores muy dinámicos que pueden difundir mensajes entre sí, creados y mantenidos por [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) en respuesta a sus movimientos en el mundo.

No existe un área predefinida ni un punto central para una isla. No son características geográficas estables, solo asociaciones temporales de jugadores cercanos. Si se puede decir que una isla cubre una región, es solo porque sus miembros están actualmente dispersos en esa zona.

Puede haber cero islas en una región sin jugadores, y varias islas superpuestas en zonas densamente pobladas, donde asignar a todos al mismo grupo haría imposible la difusión en tiempo real.

Cada servidor de la red de Decentraland puede configurar la población máxima de la isla y la distancia a la que los jugadores se consideran cercanos. Por defecto, las islas pueden albergar hasta 100 jugadores dentro de un radio de 100 metros entre sí.

El flujo para ser asignado a una isla y unirse a ella se detalla en el [Archipelago](https://github.com/decentraland/docs/tree/main/contributor/communications/archipelago/README.md) sección.

### Mensajes

Los mensajes en el protocolo de comms son blobs binarios serializados usando [protocol buffers](https://github.com/protocolbuffers/protobuf), envueltos en una [Packet](https://github.com/decentraland/docs/tree/main/contributor/communications/messages/README.md#Packet) estructura.

{% hint style="info" %}
Cuando usamos la palabra *message* en el contexto de comms, siempre nos referiremos al protocolo de mensajes binarios, no a los mensajes de chat intercambiados entre jugadores.
{% endhint %}

Hay varios tipos de mensajes diferentes, para una variedad de flujos de interacción en tiempo real. Dirígete a la [mensajes](https://github.com/decentraland/docs/tree/main/contributor/communications/messages/README.md) sección para saber más.


---

# 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-es/comunicaciones/overview.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.