Update UTP 2.0 documentation

transport_versioned_docs/version-2.0.0/about.md

@@ -2,35 +2,19 @@
 id: about
 title: About Unity Transport
 ---
-:::note
-Need an update before releasing UTP 2.0.0
-:::
 
-Unity Transport provides the `com.unity.transport` package, used to add multiplayer and network features to your project.
+The Unity Transport package (`com.unity.transport`) is a low-level networking library for multiplayer game development.
 
-:::note
-This package should not be confused with Unity Netcode's `NetworkTransport` abstraction. Please see Netcode's [Transports](/netcode/current/advanced-topics/transports) section for more information.
-:::
+It’s the underlying protocol of both [Netcode for GameObjects](../../docs/about.md) and [Netcode for Entities](https://docs.unity3d.com/Packages/com.unity.netcode@latest), but you can also use it with a custom solution.
 
-:::unity Content Licenses
-All Transport code and documentation is covered by Unity Companion License. See [Licenses](/reference/license) for more information.
-:::
+Unity Transport seamlessly supports all platforms the Unity Engine supports thanks to a connection-based abstraction layer (built-in network driver) provided over UDP and WebSockets.
 
-## Overview
+You can set up both UDP and WebSockets with or without encryption. The following illustration shows encrypted connections with a closed padlock and unencrypted connections with an open padlock.
 
-![Transport Overview](/img/transport/layercake.png)
+![Block diagram](../../static/img/transport/layercake-2.png)
 
-## Installing Transport
+You can also use [pipelines](pipelines-usage.md) to leverage additional functionality, such as reliability, packet ordering, and packet fragmentation.
 
-See the [installation guide](install.md) to install the `com.unity.transport` package.
+## Get started with Unity Transport
 
-## Using Transport
-
-To learn how to use the `com.unity.transport` package in your own project, review the client and server workflows, additional information, and sample code available in this guide.
-
-##  Requirements
-
-This version of `com.unity.transport` is compatible with the following Unity versions and platforms:
-
-* 2020.1.2 and later.
-* All platforms supported by Unity are supported, except WebGL.
+See [Getting started](getting-started.md).

transport_versioned_docs/version-2.0.0/custom-pipeline.md

@@ -4,4 +4,3 @@ title: Custom Network interface
 ---
 
 COMING SOON.
-

transport_versioned_docs/version-2.0.0/getting-started.md

@@ -3,4 +3,19 @@ id: getting-started
 title: Getting Started
 ---
 
-#PlaceHolder
+See the [Installation](install.md) guide if you’re new to Unity Transport. If you’re upgrading from a earlier version of Unity Transport, see Migrating from 1.X.
+
+Next, check out [Create a simple client and server](workflow-client-server-udp.md) and the Unity Transport [sample projects](using-sample.md).
+
+## Requirements
+
+- Install Unity Editor version 2022.2 or later.
+- Install the `com.unity.transport` package.
+
+:::note
+WebGL only supports Unity Transport WebSocket connections in client mode.
+:::
+
+:::warning
+Unity Transport (the `com.unity.transport` package) is separate from the NetworkTransport abstraction in Netcode for GameObjects.
+:::

transport_versioned_docs/version-2.0.0/install.md

@@ -4,22 +4,26 @@ title: Install Unity Transport
 description: Install Unity Transport, the com.unity.transport package, using the Package Manager.
 ---
 
-:::note
-Need an update before releasing UTP 2.0.0
-:::
-
 Follow these instructions to install Unity Transport.
 
 ## Prerequisites
 
-You need Unity Editor version 2020.1.2f1 or later.
+Unity Transport 2.0 requires Unity Editor version 2022.2 or later.
+
+:::note
+WebGL only supports Unity Transport WebSocket connections in client mode.
+:::
+
+:::warning
+Unity Transport (the com.unity.transport package) is separate from the NetworkTransport abstraction in Netcode for GameObjects.
+:::
 
 ## Install Transport
 
-1. Open the **Unity Hub**.
-1. Create a **New Project** or open an existing Project you want to include Transport.
-2. Open the **Unity Package Manager** by navigating to **Window** > **Package Manager** along the top bar.
-3. Click ![Add](/img/add.png) in the status bar.
-4. Select **Add package by name**
-5. In the **Name**, enter `com.unity.transport`. It may take a moment to load.
-6. Under **Packages** in the **Package Manager**, you should now see **Unity Transport** with it's current version number.
+You can install the Unity Transport package using the Package Manager in the Unity Editor:
+
+1. From the Unity Editor, select **Window** > **Package Manager**.
+2. Select **Add (+)** > **Add package by name**.
+3. In the **Name** field, enter com.unity.transport.
+
+After the import completes, you should see Unity Transport under **Packages** in the **Package Manager**.

transport_versioned_docs/version-2.0.0/integrate-with-unity-logging.md

@@ -0,0 +1,8 @@
+---
+id: integrate-logging
+title: Integrate with Unity Logging
+---
+
+Unity Transport integrates well with the Unity Logging package (`com.unity.logging`), an efficient alternative to the standard Unity logger. Normally, log messages go through `UnityEngine.Debug.Log`. However, if you include both packages in a project, Unity Transport automatically uses `Unity.Loggin`g with the default logger settings.
+
+Check the [`Unity.Logging` documentation site](https://docs.unity3d.com/Packages/com.unity.logging@latest) for more information on how to adjust specific log settings.

transport_versioned_docs/version-2.0.0/migration.md

@@ -1,65 +1,69 @@
 ---
 id: migration
-title: Migration from 1.X
+title: Migrate from 1.X
 description: How to deal with breaking changes introduced in version 2.0 of Unity Transport.
 ---
 
 This section describes the breaking changes introduced in version 2.0 of the Unity Transport Package (UTP). It also explains how to update projects written for version 1.X.
 
-**Note**: In most use cases, there’s no need to perform any additional steps to migrate from 1.X to 2.0. The core APIs like `NetworkDriver` remain the same, and the most significant changes are limited to specialized scenarios, such as [custom network interfaces](custom-network-interface.md).
+:::note
+In most use cases, there’s no need to perform any additional steps to migrate from 1.X to 2.0. The core APIs (like `NetworkDriver`) remain the same, and the most significant changes are limited to specialized scenarios, such as [custom network interfaces](#custom-network-interfaces).
+:::
 
 ## Editor version support
 
-UTP 1.X supports Unity Editor 2020.3 and up, but 2.0 only supports 2022.2 and up to keep the `Collections` package dependency up to date. Unity Editor 2022.2 brings many changes to the core engine runtime, allowing more code to be Burst-compiled. UTP benefits from this through increased performance.
+UTP 1.X supports Unity Editor 2020.3 and up, but 2.0 only supports 2022.2 and up to keep the Collections package dependency up to date. Unity Editor 2022.2 brings changes to the core Unity Engine runtime, allowing more code to be Burst-compiled. UTP benefits from this through increased performance.
 
-**Note**: UTP 1.X remains fully supported on LTS versions 2020.3 and 2021.3, and Unity will continue to release bug fixes and improvements. However, some features (like WebSocket support) will only be available in UTP 2.0 and up.
+:::note
+UTP 1.X remains fully supported on LTS versions 2020.3 and 2021.3, and Unity will continue to release bug fixes and improvements. However, some features (like [WebSocket](workflow-client-server-ws.md) support) will only be available in UTP 2.0 and up.
+:::
 
-## `DataStreamReader`/`DataStreamWriter` moved to `Collections`
+## DataStreamReader/DataStreamWriter moved to Collections
 
-UTP 2.0 moves the `DataStreamReader` and `DataStreamWriter` APIs to the `Collections` package to make them more widely available outside UTP. Consequently, updating to UTP 2.0 might require you to add a `Unity.Collections` directive at the top of files using the `DataStreamReader` and `DataStreamWriter` APIs.
+UTP 2.0 moves the `DataStreamReader` and `DataStreamWriter` APIs to the Collections package to make them more widely available outside UTP. As a result, updating to UTP 2.0 might require you to add a using `Unity.Collections` directive at the top of files using the `DataStreamReader` and `DataStreamWriter` APIs.
 
-The APIs are mostly unchanged, except for raw pointers. `Unity.Collections.LowLevel.Unsafe` namespace provides the raw pointer methods with `Unsafe` appended to their names. For example, the method `WriteBytes(byte*, int)` is now `WriteBytesUnsafe(byte*, int)`.
+The APIs are mostly unchanged, except for raw pointers. `Unity.Collections.LowLevel.Unsafe` namespace now provides the raw pointer methods with Unsafe appended to their names. For example, the method `WriteBytes(byte*, int)` is now `WriteBytesUnsafe(byte*, int)`.
 
 ## Protocol incompatibility
 
-The custom communication protocol UTP uses to implement connections over UDP has changed in a backward-incompatible manner, which means clients running UTP 2.0 or later can't connect to servers running 1.X, and vice versa. If you attempt to establish a connection between UTP 2.0 and UTP 1.X, it returns a connection failure after the usual timeout.
+The custom communication protocol UTP uses to implement connections over UDP has changed in a backward-incompatible manner, which means clients running UTP 2.0 or later can't connect to servers running 1.X, and vice versa. If you try to establish a connection between UTP 2.0 and UTP 1.X, UTP returns a connection failure after the usual timeout.
 
-Due to the incompatibility between UTP 2.0 and UTP 1.X, you must either ensure that you either update clients and servers simultaneously or disallow older clients from connecting to updated servers. Alternatively, you can provide different endpoints for UTP 1.X and 2.0 servers to smooth the transition while older clients are updated.
+Due to the incompatibility between UTP 2.0 and UTP 1.X, you must either ensure that you update clients and servers simultaneously or disallow older clients from connecting to updated servers. Alternatively, you can create different endpoints for UTP 1.X and 2.0 servers to smooth the transition while you update older clients.
 
-These breaking changes introduced in UTP 2.0 improve bandwidth efficiency, simplify the protocol, and lay the foundations for better forward compatibility.
+These breaking changes improve bandwidth efficiency, simplify the protocol, and lay the foundations for better forward compatibility.
 
 ## Custom network interfaces
 
 The updates in UTP 2.0 heavily modify the `INetworkInterface` API used to implement custom network interfaces (the low-level layer to send and receive packets) to simplify it.
 
-UTP 2.0 introduces the following breaking changes to custom network interfaces: 
+UTP 2.0 introduces the following breaking changes to custom network interfaces:
 
-* UTP 2.0 no longer has the concept of `NetworkInterfaceEndPoint`; the more general `NetworkEndpoint` replaces `NetworkInterfaceEndPoint`. As a result, you do not need to implement conversion logic between `NetworkEndpoint` and `NetworkInterfaceEndPoint` anymore, so `INetworkInterface` omits `CreateInterfaceEndPoint` and `GetGenericEndPoint`.
-* You no longer need to provide a `NetworkSendInterface` through `CreateSendInterface`. `ScheduleSend` handles `Send` operations, which get passed a `PacketsQueue` containing the packets to send.
-* The `ScheduleReceive` method doesn't use the (now obsolete) `NetworkPacketReceiver` to propagate received packets to the rest of UTP. Instead, implementations of `ScheduleReceive` should fill the `PacketsQueue` passed in with the received packets.
-* Implementations of `INetworkInterface` must now be fully compatible with Burst. If an implementation is incompatible with Burst, you can wrap it into a compatible implementation with the new `WrapToUnmanaged` extension method.
-* You must now create `NetworkDriver`s using a custom network interface using the static `NetworkDriver.Create` method. For example, `NetworkDriver.Create(new MyCustomInterface())` creates a `NetworkDriver `named `MyCustomInterface()`. Directly constructing a `NetworkDriver` with `new` is deprecated.
-* `INetworkInterface.Initialize` now takes another parameter: a reference to the packet padding, and you can increase this value to reserve space for headers.
+- UTP 2.0 no longer has the idea of `NetworkInterfaceEndPoint`; the more general `NetworkEndpoint` replaces `NetworkInterfaceEndPoint`. As a result, you don't need to implement conversion logic between `NetworkEndpoint` and `NetworkInterfaceEndPoint` anymore, so INetworkInterface omits `CreateInterfaceEndPoint` and `GetGenericEndPoint`.
+- You no longer need to create a `NetworkSendInterface` through `CreateSendInterface`. `ScheduleSend` handles send operations, which get passed a `PacketsQueue` containing the packets to send.
+- The `ScheduleReceive` method doesn't use the (now obsolete) `NetworkPacketReceiver` to propagate received packets to the rest of UTP. Instead, implementations of `ScheduleReceive` should fill the `PacketsQueue` passed in with the received packets.
+- Implementations of `INetworkInterface` must now be fully compatible with Burst. If an implementation is incompatible with Burst, you can wrap it into a compatible implementation with the new `WrapToUnmanaged` extension method.
+- You must now create NetworkDrivers using a custom network interface using the static `NetworkDriver.Create` method. For example, `NetworkDriver.Create(new MyCustomInterface())` creates a `NetworkDrivernamed MyCustomInterface()`. Directly constructing a NetworkDriver with new is deprecated.
+- `INetworkInterface.Initialize` now takes another parameter: a reference to the packet padding, and you can increase this value to reserve space for headers.
 
-These breaking changes simplify and increase the flexibility of the interface. See [Custom network interfaces](custom-network-interface.md) for more details on creating custom network interfaces.
+These breaking changes simplify and increase the flexibility of the interface, making it easier to create custom network interfaces.
 
 ## Pipeline stages
 
-UTP 2.0 does not introduce changes to how you write custom pipeline stages. However, the mechanisms you should use to register and get the identifier of a pipeline stage have changed:
+UTP 2.0 don't introduce changes to how you write custom pipeline stages. However, the mechanisms you should use to register and get the identifier of a pipeline stage have changed:
 
-* Instead of registering a custom pipeline stage with `NetworkPipelineStageCollection.RegisterPipelineStage`, use `NetworkDriver.RegisterPipelineStage`. Note: You must perform this change on every instance of `NetworkDriver` that uses the custom pipeline stage.
-* Instead of retrieving the ID of a pipeline stage with `NetworkPipelineStageCollection.GetStageId`, use the static `NetworkPipelineStageId.Get` method.
+- Instead of registering a custom pipeline stage with `NetworkPipelineStageCollection.RegisterPipelineStage`, use `NetworkDriver.RegisterPipelineStage`. You must do this on every instance of `NetworkDriver` that uses the custom pipeline stage.
+- Instead of retrieving the ID of a pipeline stage with `NetworkPipelineStageCollection.GetStageId`, use the static `NetworkPipelineStageId.Get` method.
 
-These breaking changes remove Burst-incompatible APIs, allowing you to use more of UTP with Burst-compiled code. 
+These breaking changes remove Burst-incompatible APIs, allowing you to use more of UTP with Burst-compiled code.
 
-For more information, see [Creating a custom pipeline stage](custom-pipeline.md) and [Pipeline usage](pipelines-usage.md).
+For more information, see the [section on using pipelines](https://docs.unity3d.com/Packages/com.unity.transport@2.0/manual/pipelines-usage.html).
 
 ## Other breaking changes
 
-In addition to the changes around data streams, custom network interfaces, and pipeline stages, UTP 2.0 also introduces the following breaking changes:
+UTP 2.0 also introduces the following breaking changes:
 
-* You must now complete a `NetworkDriver.ScheduleUpdate` job when notifying the remote peer of the disconnection after calling `NetworkDriver.Disconnect`. In 1.X, `NetworkDriver.ScheduleFlushSend` was sufficient to notify a remote peer of a disconnection, but this is not the case with UTP 2.0. This change supports new protocols, such as WebSockets, where disconnecting might involve more work than simply sending a message.
-* Using `SimulatorPipelineStageInSend` is now deprecated. Instead, use `SimulatorPipelineStage` and configure the new `ApplyMode` parameter to the direction (for example, `send`, `receive`, or both).
+* You must now complete a `NetworkDriver.ScheduleUpdate` job when notifying the remote peer of a disconnection after calling `NetworkDriver.Disconnect`. In 1.X, `NetworkDriver.ScheduleFlushSend` was enough to tell a remote peer of a disconnection, but this isn't the case with UTP 2.0. This change supports new protocols, such as WebSockets, where disconnecting might involve more work than simply sending a message.
+* Using `SimulatorPipelineStageInSend` is now deprecated. Instead, use SimulatorPipelineStage and configure the new `ApplyMode` parameter to the direction desired (send, receive, or both).
 * `NetworkSettings.WithBaselibNetworkInterfaceParameters` is now deprecated. You can no longer configure the maximum payload size; UTP handles the payload size automatically. However, you can configure the receive and send queue sizes with `NetworkSettings.WithNetworkConfigParameters`.
 * UTP 2.0 removes `NetworkSettings.WithDataStreamParameters` and `NetworkSettings.WithPipelineParameters`. You no longer need to manually configure either of these parameters, so the methods are unnecessary. You can safely delete calls to these methods.
-* You no longer need to configure `Read` and handshake timeouts through `NetworkSettings.WithSecureClientParameters` and `NetworkSettings.WithSecureServerParameters`. Instead, UTP derives the values automatically from other configuration parameters. You can safely remove these settings from these calls.
+* You no longer need to configure read and handshake timeouts through `NetworkSettings.WithSecureClientParameters` and `NetworkSettings.WithSecureServerParameters`. Instead, UTP derives the values automatically from other configuration parameters. You can safely remove these settings from these calls.