-
Notifications
You must be signed in to change notification settings - Fork 216
MTT-4370: UTP 2.0 migration guide #752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
It is thus recommended to ensure that clients and servers are updated at the same time, or to disallow older clients from connecting once the server is updated. Another strategy is to offer different endpoints for UTP 1.X and 2.0 servers, which could smooth the transition while older clients are updated. | ||
|
||
The reasons for this breaking change are to improve bandwidth efficiency, simplify the protocol, and (ironically) improve forward-compatibility of the protocol. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "(Ironically)" piece contrast with the doc. Could we use something like :
and lays the foundations for better forward compatibility of the protocol.
|
||
## Other breaking changes | ||
|
||
* After calling `NetworkDriver.Disconnect`, notifying the remote peer of the disconnection now requires completing a `NetworkDriver.ScheduleUpdate` job. In 1.X, `NetworkDriver.ScheduleFlushSend` used to be sufficient for this purpose but it's not the case anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the document is factual without explanation, I think this is the correct approach.
However, for this, we are adding an extra step for the user. The natural reaction will be to wonder why.
Would an explanation make sense here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@johann-r-unity - Forgive me for lacking context here; I'm not sure I understand entirely. Are you saying we should add an explanation around why we introduced these additional breaking changes (similar to the explanation at the end of the previous paragraphs)?
For example:
These breaking changes simplify and increase the flexibility of the interface. Please refer to this documentation section for more details on creating custom network interfaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Larah,
My initial comment is outdated. Simon did the required modification already.
* There is no concept of `NetworkInterfaceEndPoint` anymore. It has been completely replaced with the more general `NetworkEndpoint`. Consequently, there is no need to implement conversion logic between the two anymore (so `CreateInterfaceEndPoint` and `GetGenericEndPoint` were removed from `INetworkInterface`). | ||
* There is no need to provide a `NetworkSendInterface` through `CreateSendInterface` anymore. Send operations are now handled entirely by `ScheduleSend`, which gets passed a `PacketsQueue` containing the packets to be sent. | ||
* The `ScheduleReceive` method doesn't use `NetworkPacketReceiver` (which is now obsolete) to propagate received packets to the rest of UTP. Instead, implementations of `ScheduleReceive` are expected to fill the `PacketsQueue` that is now passed in with the received packets. | ||
* Implementations of `INetworkInterface` are now expected to be fully unmanaged. However, a managed implementation can be wrapped into an unmanaged one with the new `WrapToUnmanaged` extension method. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the term unmanaged I think will leave folks confused. It almost sounds like the interface must be written in native code which isn't really what you are saying. What you are saying is that it must be fully burst compatible unless you are using the wrapper.
Is 2.0 going to depend on 2.0 of collections? I noticed that in that version of collections DataStream and NetworkCompression are now part of collections. |
@wackoisgod , yes. |
If that's the case then it may be worth it to call out those changes. Also if I recall collections 2.0 requires Unity 2022.2 according to the preview release. Does that mean 2.0 will require that? |
You are correct. It will be available with the Editor starting 2022.2. |
So does this mean you will continue to support 1.x and make fixes and updates for that version? My worry is that 2.0 will be out while two LTS versions are out under 1.x since it doesn't seem things are backwards compatible. |
Yes. As long as there are supported LTS versions that only support UTP 1.X, we'll keep supporting it. Some new features may only make it in 2.0, however. |
…Technologies/com.unity.multiplayer.docs into transport/migration-guide
* delete event loop file from TP v2.0 docs (#799) * delete event loop file from TP v2.0 docs delete event loop file from TP v2.0 docs * Removing event loop from sidebars Removing event loop from sidebars * Update NGO changelog for 1.0.1 and 1.0.2 (#774) * Fixed typo in github link (#765) https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/main/Assets/Scripts/Gameplay/ConnectionManagement/ServerGameNetPortal.css#L176 => https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/main/Assets/Scripts/Gameplay/ConnectionManagement/ServerGameNetPortal.cs#L176 * update changelog for NGO 1.0.1 and 1.0.2 * MTT-4369 Update UTP documentation to 2.0 documentation structure * Update version-2.0.0-sidebars.json * Removed .bak files * Update NGO 1.0.1 changelog Co-authored-by: Grave <[email protected]> Co-authored-by: Johann Ruwet <[email protected]> * Add changelog for UTP 1.3.0 (#801) * fix broken link to client driven sample (#804) * delete event loop file on main (#798) * delete event loop file on main delete event loop file on main, retaining on develop * Update TP v sidebars.js Update TP v sidebars.js removing from TOC * Update version-2.0.0-sidebars.json Co-authored-by: Brian Coughlin <[email protected]> * Fix broken link to client-driven sample Fix broken link to client-driven sample Co-authored-by: Brian Coughlin <[email protected]> Co-authored-by: Larah Armstrong <[email protected]> * Sync sidebar (#808) * delete event loop file on main (#798) * delete event loop file on main delete event loop file on main, retaining on develop * Update TP v sidebars.js Update TP v sidebars.js removing from TOC * Update version-2.0.0-sidebars.json Co-authored-by: Brian Coughlin <[email protected]> * Update NGO changelog for 1.0.1 and 1.0.2 (#774) * Fixed typo in github link (#765) https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/main/Assets/Scripts/Gameplay/ConnectionManagement/ServerGameNetPortal.css#L176 => https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/main/Assets/Scripts/Gameplay/ConnectionManagement/ServerGameNetPortal.cs#L176 * update changelog for NGO 1.0.1 and 1.0.2 * MTT-4369 Update UTP documentation to 2.0 documentation structure * Update version-2.0.0-sidebars.json * Removed .bak files * Update NGO 1.0.1 changelog Co-authored-by: Grave <[email protected]> Co-authored-by: Johann Ruwet <[email protected]> * delete event loop file from TP v2.0 docs (#799) * delete event loop file from TP v2.0 docs delete event loop file from TP v2.0 docs * Removing event loop from sidebars Removing event loop from sidebars * Add changelog for UTP 1.3.0 (#801) * fix broken link to client driven sample (#804) * delete event loop file on main (#798) * delete event loop file on main delete event loop file on main, retaining on develop * Update TP v sidebars.js Update TP v sidebars.js removing from TOC * Update version-2.0.0-sidebars.json Co-authored-by: Brian Coughlin <[email protected]> * Fix broken link to client-driven sample Fix broken link to client-driven sample Co-authored-by: Brian Coughlin <[email protected]> Co-authored-by: Larah Armstrong <[email protected]> * Fix sidebar Co-authored-by: Christopher Pope <[email protected]> Co-authored-by: Brian Coughlin <[email protected]> Co-authored-by: Grave <[email protected]> Co-authored-by: Johann Ruwet <[email protected]> * MTT-4370: UTP 2.0 migration guide (#752) * Preliminary version of the UTP 2.0 migration guide * Address review comments * Mention breaking change in INetworkInterface.Initialize * Add sections on editor support and collections update * Preliminary version of the UTP 2.0 migration guide * Address review comments * Mention breaking change in INetworkInterface.Initialize * Add sections on editor support and collections update * Minor adjustments to the UTP 2.0 migration guide * Minor fixes Co-authored-by: Larah Armstrong <[email protected]> Co-authored-by: Larah Armstrong <[email protected]> Co-authored-by: Larah Armstrong <[email protected]> Co-authored-by: Grave <[email protected]> Co-authored-by: Johann Ruwet <[email protected]> Co-authored-by: Brian Coughlin <[email protected]> Co-authored-by: Simon Lemay <[email protected]> Co-authored-by: Larah Armstrong <[email protected]>
Select the type of change:
Purpose of the Pull Request:
This PR introduces the migration guide when updating from UTP 1.X to 2.0. The intent is to leave it as a draft for now since we might have more breaking changes to add in there as we move closer to the release.
Before merging, I'll also update the PR so that most of the APIs link to their API page. I didn't do so right away to make the markdown file easier on the eyes while we review it.
Issue Number: MTT-4370