Merge pull request #291845 from spelluru/relayfreshness1211

prmerger-automator[bot] · web-flow · commit 4b3ed7276132 · 2024-12-11T22:23:01.000Z
Azure Relay freshness review
diff --git a/articles/azure-relay/includes/trusted-services.md b/articles/azure-relay/includes/trusted-services.md
@@ -2,7 +2,7 @@
 author: spelluru
 ms.service: azure-relay
 ms.topic: include
-ms.date: 06/26/2023
+ms.date: 12/11/2024
 ms.author: spelluru
 ---
 
@@ -11,11 +11,11 @@ When you enable the **Allow trusted Microsoft services to bypass this firewall**
 
 | Trusted service | Supported usage scenarios | 
 | --------------- | ------------------------- | 
-| Azure Machine Learning | AML Kubernetes uses Azure Relay to facilitate communication between AML services and the Kubernetes cluster. Azure Relay is a fully managed service that provides secure bi-directional communication between applications hosted on different networks. This makes it ideal for use in private link environments, where communication between Azure resources and on-premises resources is restricted. |
-| Azure Arc | Azure Arc-enabled services associated with the Resource Providers above will be able to connect to the hybrid connections in your Azure Relay namespace as a sender without being blocked by the IP firewall rules set on the Azure Relay namespace. `Microsoft.Hybridconnectivity` service creates the hybrid connections in your Azure Relay namespace and provides the connection information to the relevant Arc service based on the scenario. These services communicate only with your Azure Relay namespace if you're using Azure Arc, with the following Azure Services: <br/><br> - Azure Kubernetes<br/> - Azure Machine Learning <br/> - Microsoft Purview |
+| Azure Machine Learning | AML Kubernetes uses Azure Relay to facilitate communication between AML services and the Kubernetes cluster. Azure Relay is a fully managed service that provides secure bi-directional communication between applications hosted on different networks. This feature makes it ideal for use in private link environments, where communication between Azure resources and on-premises resources is restricted. |
+| Azure Arc | Azure Arc-enabled services associated with the resource providers can connect to the hybrid connections in your Azure Relay namespace as a sender without being blocked by the IP firewall rules set on the Azure Relay namespace. `Microsoft.Hybridconnectivity` service creates the hybrid connections in your Azure Relay namespace and provides the connection information to the relevant Arc service based on the scenario. These services communicate only with your Azure Relay namespace if you're using Azure Arc, with the following Azure Services: <br/><br> - Azure Kubernetes<br/> - Azure Machine Learning <br/> - Microsoft Purview |
 
 
-The other trusted services for Azure Relay can be found below:
+The other trusted services for Azure Relay are:
 - Azure Event Grid
 - Azure IoT Hub
 - Azure Stream Analytics
@@ -35,7 +35,7 @@ The other trusted services for Azure Relay can be found below:
 > "trustedServiceAccessEnabled": "True"
 > ```
 
-For example, based on the ARM template provided above, we can modify it to include this Network Rule Set property for the enablement of Trusted Services:
+For example, based on the ARM template provided, you can modify it to include this Network Rule Set property for the enablement of Trusted Services:
 
 ```json
 {
diff --git a/articles/azure-relay/relay-hybrid-connections-http-requests-dotnet-get-started.md b/articles/azure-relay/relay-hybrid-connections-http-requests-dotnet-get-started.md
@@ -1,12 +1,13 @@
 ---
-title: Azure Relay Hybrid Connections - HTTP requests in .NET
-description: Write a C# console application for Azure Relay Hybrid Connections HTTP requests in .NET.
+title: Hybrid Connections - HTTP requests in .NET
+description: Provides step-by-step instructions to create a C# console application for Azure Relay Hybrid Connections HTTP requests in .NET.
 ms.topic: tutorial
 ms.custom: devx-track-csharp, mode-ui, mode-api, devx-track-dotnet
-ms.date: 08/10/2023
+ms.date: 12/11/2024
+# Customer intent: I want to learn how to create a .NET app to send and receive messages by using the HTTP protocol. 
 ---
 
-# Get started with Relay Hybrid Connections HTTP requests in .NET
+# Tutorial: Get started with Relay Hybrid Connections HTTP requests in .NET
 [!INCLUDE [relay-selector-hybrid-connections](./includes/relay-selector-hybrid-connections.md)]
 
 In this quickstart, you create .NET sender and receiver applications that send and receive messages by using the HTTP protocol. The applications use Hybrid Connections feature of Azure Relay. To learn about Azure Relay in general, see [Azure Relay](relay-what-is-it.md). 
@@ -52,9 +53,8 @@ In Visual Studio, write a C# console application to send messages to the relay.
 1. Run the client application. You see `hello!` in the client window. The client sent an HTTP request to the server, and server responded with a `hello!`. 
 3. Now, to close the console windows, press **ENTER** in both the console windows. 
 
-Congratulations, you've created a complete Hybrid Connections application!
 
-## Next steps
+## Related content
 
 In this quickstart, you created .NET client and server applications that used HTTP to send and receive messages. The Hybrid Connections feature of Azure Relay also supports using WebSockets to send and receive messages. To learn how to use WebSockets with Azure Relay Hybrid Connections, see the [WebSockets quickstart](relay-hybrid-connections-dotnet-get-started.md).
 
diff --git a/articles/azure-relay/relay-hybrid-connections-node-ws-api-overview.md b/articles/azure-relay/relay-hybrid-connections-node-ws-api-overview.md
@@ -2,15 +2,15 @@
 title: Overview of the Azure Relay Node APIs | Microsoft Docs
 description: This article provides an overview of the Node.js API for the Azure Relay service. It also shows how to use the hyco-ws Node package. 
 ms.topic: article
-ms.date: 08/10/2023
+ms.date: 12/11/2024
 ms.custom: devx-track-js
 ---
 
 # Relay Hybrid Connections Node.js API overview
 
 ## Overview
 
-The [`hyco-ws`](https://www.npmjs.com/package/hyco-ws) Node package for Azure Relay Hybrid Connections is built on and extends the [`ws`](https://www.npmjs.com/package/ws) NPM package. This package re-exports all exports of that base package and adds new exports that enable integration with the Azure Relay service Hybrid Connections feature. 
+The [`hyco-ws`](https://www.npmjs.com/package/hyco-ws) Node package for Azure Relay Hybrid Connections is built on and extends the [`ws`](https://www.npmjs.com/package/ws) Node Package Manager (npm) package. This package re-exports all exports of that base package and adds new exports that enable integration with the Azure Relay service Hybrid Connections feature. 
 
 Existing applications that `require('ws')` can use this package with `require('hyco-ws')` instead, which also enables hybrid scenarios in which an application can listen for WebSocket connections locally from "inside the firewall" and via Hybrid Connections, all at the same time.
   
@@ -123,17 +123,17 @@ Constructor arguments:
 
 #### Events
 
-`RelayedServer` instances emit three events that enable you to handle incoming requests, establish connections, and detect error conditions. You must subscribe to the `connect` event to handle messages. 
+`RelayedServer` instances emit three events that enable you to handle incoming requests, establish connections, and detect the error conditions. You must subscribe to the `connect` event to handle messages. 
 
-##### headers
+##### Headers
 
 ```JavaScript 
 function(headers)
 ```
 
 The `headers` event is raised just before an incoming connection is accepted, enabling modification of the headers to send to the client. 
 
-##### connection
+##### Connection
 
 ```JavaScript
 function(socket)
@@ -142,7 +142,7 @@ function(socket)
 Emitted when a new WebSocket connection is accepted. The object is of type `ws.WebSocket`, same as with the base package.
 
 
-##### error
+##### Error
 
 ```JavaScript
 function(error)
diff --git a/articles/azure-relay/relay-hybrid-connections-protocol.md b/articles/azure-relay/relay-hybrid-connections-protocol.md
@@ -2,7 +2,7 @@
 title: Azure Relay Hybrid Connections protocol guide | Microsoft Docs
 description: This article describes the client-side interactions with the Hybrid Connections relay for connecting clients in listener and sender roles.
 ms.topic: article
-ms.date: 08/10/2023
+ms.date: 12/11/2024
 ---
 
 # Azure Relay Hybrid Connections protocol
@@ -12,7 +12,7 @@ platform. The new _Hybrid Connections_ capability of Relay is a secure,
 open-protocol evolution based on HTTP and WebSockets. It supersedes the former,
 equally named _BizTalk Services_ feature that was built on a proprietary
 protocol foundation. The integration of Hybrid Connections into Azure App
-Services will continue to function as-is.
+Services continue to function as-is.
 
 Hybrid Connections enables bi-directional, request-response, and binary stream communication, and
 simple datagram flow between two networked applications. Either or
@@ -42,8 +42,8 @@ to be accepted for establishing a bi-directional communication path. "Connect,"
 "Listen," and "Accept" are the same terms you find in most socket APIs.
 
 Any relayed communication model has either party making outbound connections
-towards a service endpoint. This makes the "listener" also a "client" in
-colloquial use, and may also cause other terminology overloads. The precise
+towards a service endpoint. It makes the "listener" also a "client" in
+colloquial use, and might also cause other terminology overloads. The precise
 terminology therefore used for Hybrid Connections is as follows:
 
 The programs on both sides of a connection are called "clients," since they're
@@ -115,8 +115,8 @@ The listener can respond to HTTP requests using an equivalent response gesture.
 The request/response flow uses the control channel by default, but can be
 "upgraded" to a distinct rendezvous WebSocket whenever required. Distinct
 WebSocket connections improve throughput for each client conversation, but they
-burden the listener with more connections that need to be handled, which may
-not be desire able for lightweight clients.
+burden the listener with more connections that need to be handled, which might
+not be desirable for lightweight clients.
 
 On the control channel, request and response bodies are limited to at most 64 kB
 in size. HTTP header metadata is limited to a total of 32 kB. If either the
@@ -125,7 +125,7 @@ to a rendezvous WebSocket using a gesture equivalent to handling the
 [Accept](#accept-message).
 
 For requests, the service decides whether to route requests over the control
-channel. This includes, but may not be limited to cases where a request exceeds
+channel. It includes, but might not be limited to cases where a request exceeds
 64 kB (headers plus body) outright, or if the request is sent with ["chunked"
 transfer-encoding](https://tools.ietf.org/html/rfc7230#section-4.1) and the
 service has reason to expect for the request to exceed 64 kB or reading the
@@ -145,17 +145,17 @@ response over the established rendezvous socket.
 
 Once the rendezvous WebSocket has been established, the listener SHOULD
 maintain it for further handling of requests and responses from the same
-client. The service will maintain the WebSocket for as long as the HTTPS socket
-connection with the sender persists and will route all subsequent requests from
+client. The service maintains the WebSocket for as long as the HTTPS socket
+connection with the sender persists and routes all subsequent requests from
 that sender over the maintained WebSocket. If the listener chooses to drop the
-rendezvous WebSocket from its side, the service will also drop the connection
+rendezvous WebSocket from its side, the service also drops the connection
 to the sender, irrespective of whether a subsequent request might already be
 in progress.
 
 #### Renew operation
 
 The security token that must be used to register the listener and maintain the
-control channel may expire while the listener is active. The token expiry doesn't affect ongoing connections, but it does cause the control channel to be
+control channel might expire while the listener is active. The token expiry doesn't affect ongoing connections, but it does cause the control channel to be
 dropped by the service at or soon after the moment of expiry. The "renew"
 operation is a JSON message that the listener can send to replace the token
 associated with the control channel, so that the control channel can be
@@ -164,7 +164,7 @@ maintained for extended periods.
 #### Ping operation
 
 If the control channel stays idle for a long time, intermediaries on the way,
-such as load balancers or NATs may drop the TCP connection. The "ping"
+such as load balancers or NATs might drop the TCP connection. The "ping"
 operation avoids that by sending a small amount of data on the channel that
 reminds everyone on the network route that the connection is meant to be alive,
 and it also serves as a "live" test for the listener. If the ping fails, the
@@ -279,7 +279,7 @@ The query string parameter options are as follows.
 If the WebSocket connection fails due to the Hybrid Connection path not being
 registered, or an invalid or missing token, or some other error, the error
 feedback is provided using the regular HTTP 1.1 status feedback model. The
-status description contains an error tracking-id that can be communicated to
+status description contains an error tracking ID that can be communicated to
 Azure support personnel:
 
 | Code | Error          | Description
@@ -308,7 +308,7 @@ The "accept" notification is sent by the service to the listener over the
 previously established control channel as a JSON message in a WebSocket text
 frame. There's no reply to this message.
 
-The message contains a JSON object named "accept", which defines the following
+The message contains a JSON object named `accept`, which defines the following
 properties at this time:
 
 * **address** – the URL string to be used for establishing the WebSocket to the
@@ -362,7 +362,7 @@ following parameters:
 Connection on which to register this listener. This expression is appended to the
 fixed `$hc/` path portion.
 
-The `path` expression may be extended with a suffix and a query string
+The `path` expression might be extended with a suffix and a query string
 expression that follows the registered name after a separating forward slash.
 This parameter enables the sender client to pass dispatch arguments to the accepting
 listener when it isn't possible to include HTTP headers. The expectation is
@@ -430,7 +430,7 @@ The `request` consists of two parts: a header and binary body frame(s).
 If there's no body, the body frames are omitted. The boolean `body` property indicates whether a body is present in the request
 message.
 
-For a request with a request body, the structure may look like this:
+For a request with a request body, the structure might look like this:
 
 ``` text
 ----- Web Socket text frame ----
@@ -522,7 +522,7 @@ The JSON content for `request` is as follows:
 The receiver MUST respond. Repeated failure to respond to requests while
 maintaining the connection might result in the listener getting blocked.
 
-Responses may be sent in any order, but each request must be responded to
+Responses might be sent in any order, but each request must be responded to
 within 60 seconds or the delivery will be reported as having failed. The
 60-second deadline is counted until the `response` frame has been received
 by the service. An ongoing response with multiple binary frames can't
@@ -532,15 +532,15 @@ If the request is received over the control channel, the response MUST
 either be sent on the control channel from where the request was received
 or it MUST be sent over a rendezvous channel.
 
-The response is a JSON object named "response". The rules for handling
+The response is a JSON object named `response`. The rules for handling
 body content are exactly like with the `request` message and based on
 the `body` property.
 
 * **requestId** – string. REQUIRED. The `id` property value of the `request` message being
   responded to.
 * **statusCode** – number. REQUIRED. a numerical HTTP status code that indicates the outcome of
   the notification. All status codes of [RFC7231, Section 6](https://tools.ietf.org/html/rfc7231#section-6)
-  are permitted, except for [502 "Bad Gateway"](https://tools.ietf.org/html/rfc7231#section-6.6.3) and [504 "Gateway Timeout"](https://tools.ietf.org/html/rfc7231#section-6.6.5).
+  are permitted, except for [502 "Bad Gateway"](https://tools.ietf.org/html/rfc7231#section-6.6.3) and [504 - Gateway Timeout](https://tools.ietf.org/html/rfc7231#section-6.6.5).
 * **statusDescription** - string. OPTIONAL. HTTP status-code reason phrase per [RFC7230, Section 3.1.2](https://tools.ietf.org/html/rfc7230#section-3.1.2)
 * **responseHeaders** – HTTP headers to be set in an external HTTP reply.
   As with the `request`, RFC7230 defined headers MUST NOT be used.
@@ -658,7 +658,7 @@ The query string parameter options are as follows:
  extended with a suffix and a query string expression to communicate further. If
  the Hybrid Connection is registered under the path `hyco`, the `path`
  expression can be `hyco/suffix?param=value&...` followed by the query string
- parameters defined here. A complete expression may then be as follows:
+ parameters defined here. A complete expression might then be as follows:
 
 ```
 wss://{namespace-address}/$hc/hyco/suffix?param=value&sb-hc-action=...[&sb-hc-id=...&]sb-hc-token=...
diff --git a/articles/azure-relay/relay-metrics-azure-monitor.md b/articles/azure-relay/relay-metrics-azure-monitor.md
@@ -3,7 +3,7 @@ title: Azure Relay metrics in Azure Monitor  | Microsoft Docs
 description: This article provides information on how you can use Azure Monitor to monitor to state of Azure Relay. 
 services: service-bus-relay
 ms.topic: article
-ms.date: 08/10/2023
+ms.date: 12/11/2024
 ---
 
 # Azure Relay metrics in Azure Monitor 
@@ -32,7 +32,7 @@ For metrics supporting dimensions, you must filter with the desired dimension va
 
 ## Billing
 
-Using metrics in Azure Monitor is currently free while in preview. However, if you use additional solutions that ingest metrics data, you may be billed by these solutions. For example, you're billed by Azure Storage if you archive metrics data to an Azure Storage account. You're also billed by Azure Monitor logs if you stream metrics data to Azure Monitor logs for advanced analysis.
+Using metrics in Azure Monitor is currently free while in preview. However, if you use additional solutions that ingest metrics data, you might be billed by these solutions. For example, you're billed by Azure Storage if you archive metrics data to an Azure Storage account. You're also billed by Azure Monitor logs if you stream metrics data to Azure Monitor logs for advanced analysis.
 
 The following metrics give you an overview of the health of your service. 
 
diff --git a/articles/azure-relay/relay-port-settings.md b/articles/azure-relay/relay-port-settings.md
@@ -2,7 +2,7 @@
 title: Azure Relay port settings | Microsoft Docs
 description: This article includes a table that describes the required configuration for port values for Azure Relay.
 ms.topic: article
-ms.date: 08/10/2023
+ms.date: 12/11/2024
 ---
 
 # Azure Relay port settings
@@ -11,9 +11,9 @@ The following table describes the required configuration for port values for Azu
 
 ## Hybrid Connections
 
-Hybrid Connections uses WebSockets on port 443 with TLS as the underlying transport mechanism, which uses **HTTPS** only. 
+Hybrid Connections uses WebSockets on port 443 with Transport Layer Security (TLS) as the underlying transport mechanism, which uses **HTTPS** only. 
 
-## WCF Relays
+## Windows Communication Foundation (WCF) Relays
   
 |Binding|Transport Security|Port|  
 |-------------|------------------------|----------|  
diff --git a/articles/azure-relay/service-bus-dotnet-hybrid-app-using-service-bus-relay.md b/articles/azure-relay/service-bus-dotnet-hybrid-app-using-service-bus-relay.md
diff --git a/articles/azure-relay/service-bus-relay-rest-tutorial.md b/articles/azure-relay/service-bus-relay-rest-tutorial.md
diff --git a/articles/azure-relay/service-bus-relay-tutorial.md b/articles/azure-relay/service-bus-relay-tutorial.md
