Update terms for MQTT

Author: Y-Sindo

articles/azure-web-pubsub/includes/terms.md

@@ -6,7 +6,7 @@ ms.topic: include
 ms.date: 01/23/2024
 ---
 
-- **Connection**: A connection, also known as a client or a client connection, represents an individual WebSocket connection connected to the Web PubSub service. When successfully connected, a unique connection ID is assigned to this connection by the Web PubSub service.
+- **Connection**: A connection, also known as a client or a **client connection**, it's a logical relationship between a client and the Web PubSub service. Over a 'connection', the client and the service engage in a series of stateful interactions. **Connections** using different protocols might behave differently, for example, some **connection** are limited to the duration of a network connection, while others can extend across multiple successive network connections between a client and the service.
 
 - **Hub**: A hub is a logical concept for a set of client connections. Usually you use one hub for one scenario, for example, a *chat* hub, or a *notification* hub. When a client connection connects, it connects to a hub, and during its lifetime it belongs to that hub. Once a client connection connects to the hub, the hub exists. Different applications can share one Azure Web PubSub service by using different hub names. While there is no strict limit on the number of hubs, a **hub** consumes more service load comparing to a **group**. It is recommended to have a predetermined set of hubs rather than generating them dynamically.
 
@@ -16,8 +16,6 @@ ms.date: 01/23/2024
 
 - **Message**: When the client is connected, it can send messages to the upstream application, or receive messages from the upstream application, through the WebSocket connection. Messages can be in plain text, binary, or JSON format and have a maximum size of 1 MB.
 
-- **Client Connection** and **ConnectionId**: A client connects to the `/client` endpoint, when connected, a unique `connectionId` is generated by the service as the unique identity of the client connection. Users can then manage the client connection using this `connectionId`. Details are described in [Client protocol](..\concept-service-internals.md#client-protocol) section.
-
 - **Client Events**: Events are created during the lifecycle of a client connection. For example, a simple WebSocket client connection creates a `connect` event when it tries to connect to the service, a `connected` event when it successfully connected to the service, a `message` event when it sends messages to the service and a `disconnected` event when it disconnects from the service. Details about *client events* are illustrated in [Client protocol](..\concept-service-internals.md#client-protocol) section.
 
 - **Event Handler**: The event handler contains the logic to handle the client events. Register and configure event handlers in the service through the portal or Azure CLI beforehand. Details are described in [Event handler](..\concept-service-internals.md#event-handler) section.

articles/azure-web-pubsub/key-concepts.md

@@ -30,7 +30,7 @@ A typical workflow using the service is shown as below:
 
 As illustrated by the above workflow graph:
 
-1. A *client* connects to the service `/client` endpoint using WebSocket transport. Service forward every WebSocket frame to the configured upstream(server). The WebSocket connection can connect with any custom subprotocol for the server to handle, or it can connect with the service-supported subprotocols (e.g. `json.webpubsub.azure.v1`) that enable the clients to do pub/sub directly. Details are described in [client protocols](concept-service-internals.md#client-protocol).
+1. A *client* connects to a hub in the service using WebSocket transport. The service may forward the messages to the configured upstream(server), or handle the messages on its own and allow the clients to do pub/sub directly, depending on the protocol the client uses. Details are described in [client protocols](concept-service-internals.md#client-protocol).
 
 2. The service invokes the server using **CloudEvents protocol** on different client events. [**CloudEvents**](https://github.com/cloudevents/spec/blob/v1.0.1/spec.md) is a standardized and protocol-agnostic definition of the structure and metadata description of events hosted by the Cloud Native Computing Foundation (CNCF). Details are described in [server protocol](concept-service-internals.md#server-protocol).