docs: NetworkConfig.ClientConnectionBufferTimeout [skip ci]#1927
docs: NetworkConfig.ClientConnectionBufferTimeout [skip ci]#1927JesseOlmer merged 3 commits intodevelopfrom
Conversation
Add more detail to where in the process the setting takes effect, how it relates to transport-level timeouts, and indicates that it's a server-side setting only.
| /// <summary> | ||
| /// The amount of seconds to wait for handshake to complete before timing out a client | ||
| /// The amount of seconds for the server to wait for the connection approval handshake to complete before the client is disconnected. | ||
| /// |
There was a problem hiding this comment.
| /// | |
| /// This could happen if for example you're calling external services to authenticate your users and those services timeout. |
For users that never worked on connected games, this could help.
There was a problem hiding this comment.
This isn't the appropriate type of comment to add to a Summary section. I'll add some similar flavor to Remarks
| /// The period begins after the <see cref="NetworkEvent.Connect"/> is received on the server. | ||
| /// The period ends once the server finishes processing a <see cref="ConnectionRequestMessage"/> from the client. | ||
| /// | ||
| /// This setting is independent of any Transport-level timeouts that may be in effect. |
There was a problem hiding this comment.
| /// This setting is independent of any Transport-level timeouts that may be in effect. | |
| /// This setting is independent of any Transport-level timeouts that may be in effect. To calculate the overall connection timeout for a player connecting to a server, add transport + buffer timeout. |
There was a problem hiding this comment.
In the new draft there are already 3-4 other references to the Transport timeout so I don't feel this explicit calculation one is necessary. It's also not necessarily accurate depending on Transport implementations.
There was a problem hiding this comment.
How about something like "a player's total connection timeout would be influenced by both transport side (if any) and network manager side timeouts". It'd just help give the big picture to users, right now we're showing this as if they were two tech in silos.
SamuelBellomo
left a comment
There was a problem hiding this comment.
added some nitpicking, looks good otherwise
Add more context and detail to the time period affected by this setting.
…ns [skip ci] (#1927) Add more detail to where in the process the setting takes effect, how it relates to transport-level timeouts and indicates that it's a server-side setting only.
…ns [skip ci] (#1927) Add more detail to where in the process the setting takes effect, how it relates to transport-level timeouts and indicates that it's a server-side setting only.
* chore: Separate trunk tests and trigger weekly (#1926) * chore: Separate trunk tests and trigger weekly * Rename to weekly * Turn off badges trigger dependencies on trunk * Run Code Coverage on validation_editor 2020.3 * fix: Fix code coverage config name in nightly trigger (#1933) * docs: NetworkConfig.ClientConnectionBufferTimeout xmldoc clarifications [skip ci] (#1927) Add more detail to where in the process the setting takes effect, how it relates to transport-level timeouts and indicates that it's a server-side setting only. * chore: update `CODEOWNERS` (#1935) Co-authored-by: Jesse Olmer <jesseo@unity3d.com> Co-authored-by: Fatih Mar <mfatihmar@gmail.com>
Add more detail to where in the process the setting takes effect, how it relates to transport-level timeouts and indicates that it's a server-side setting only.
Note that in documenting this, I discovered that connection approval timeout appears bugged/inoperable on the client-side and has been that way for a very long time. Will file a follow-up issue.
Changelog
Testing and Documentation