Add separate knob for TCP server listen enabling. #36979
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review changes with |
133ccd7 to
7699ee4
Compare
|
PR #36979: Size comparison from e7f6d0e to 7699ee4 Full report (19 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, nrfconnect, qpg, stm32, tizen)
|
|
PR #36979: Size comparison from e7f6d0e to ec213db Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
andy31415
reviewed
Jan 9, 2025
andy31415
reviewed
Jan 9, 2025
Use a boolean indicator for TCP server enabling in the TCPListenParameters to signal Server enabling during initialization. By default, TCP Server is enabled on the Server side, and disabled on the client/controller side. Add API in TransportMgr to access this setting so that DNS-SD operational advertisements for TCP can be set accordingly.
366359b to
24df222
Compare
Co-authored-by: Andrei Litvin <[email protected]>
24df222 to
1ba654a
Compare
|
PR #36979: Size comparison from d3204f6 to 1ba654a Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
andy31415
approved these changes
Jan 9, 2025
aronrosenberg
approved these changes
Jan 9, 2025
|
|
||
| #if INET_CONFIG_ENABLE_TCP_ENDPOINT | ||
| , | ||
| TcpListenParameters(DeviceLayer::TCPEndPointManager()) |
Contributor
There was a problem hiding this comment.
This needs some documentation explaining that the ordering here is very important and pointing to the code that depends on that ordering.
Contributor
Author
There was a problem hiding this comment.
Going to add the documentation in a subsequent PR. Had intended to do so in this one but it auto-merged before that.
| #endif // CHIP_CONFIG_ENABLE_ICD_SERVER | ||
|
|
||
| #if INET_CONFIG_ENABLE_TCP_ENDPOINT | ||
| app::DnssdServer::Instance().SetTCPServerEnabled(mTransports.GetTransport().GetImplAtIndex<1>().IsServerListenEnabled()); |
Contributor
There was a problem hiding this comment.
So this is weird. I would have expected the TcpListenParameters to tell the transport whether to enable server, not the transport deciding independently and then the Server having to get the info out somehow. And indeed the parameters have a flag for this. So what's going on here?
In particular, looks to me like Server always enables listen, so this whole IsServerListenEnabled complexity is not needed....
Contributor
Author
There was a problem hiding this comment.
The TcpListenParameters does carry the flag and it is set while initializing the TransportMgr. The way I have it in this PR is enabling the Server as a default setting in TcpListenParameters. The controller explicitly sets it to false.
For setting it in the DnssdServer, it is being retrieved from the Transport using the logic above because the setting in the TransportMgr is being assumed to be the source of truth.
| .SetAddressType(Inet::IPAddressType::kIPv6) | ||
| .SetListenPort(params.listenPort) | ||
| #if INET_CONFIG_ENABLE_IPV4 | ||
| #if INET_CONFIG_ENABLE_TCP_ENDPOINT |
Contributor
There was a problem hiding this comment.
Why the ordering change here?
Contributor
There was a problem hiding this comment.
And note that the ordering here is public API certainly for Server, so you have no idea whom you might be breaking with these ordering changes. Like "introduces silent security bugs" breaking.
| Transport::TcpListenParameters(stateParams.tcpEndPointManager) | ||
| .SetAddressType(IPAddressType::kIPv6) | ||
| .SetListenPort(params.listenPort) | ||
| .SetServerListenEnabled(false) // Initialize as a TCP Client |
Contributor
There was a problem hiding this comment.
Wait, why would we force controllers to never be TCP servers? This isn't a "by default" like the PR description misleadingly says: it's just force-disabled.
Contributor
Author
There was a problem hiding this comment.
In order to keep the interaction simple, I was assuming controllers(like chip-tool and commissioning clients) to be TCP clients.
The TcpListenParameters probably need to be percolated further up in order to make it a truly configurable parameter. For now, I have set the controller to be a TCP Client.
| return TCPDisconnectImpl<0>(conn, shouldAbort); | ||
| } | ||
|
|
||
| bool IsServerListenEnabled() override { return IsServerListenEnabledImpl<0>(); } |
Contributor
There was a problem hiding this comment.
Is this used? It doesn't seem to be used. The one use in Server gets something explicitly by index...
And what does this function even mean? "We have some transport that's listening as a server"?
What does it even mean for a generic transport (e.g. UDP) to be "listening as a server"?
Contributor
|
Here's what I propose concretely:
|
Alami-Amine
pushed a commit
to Alami-Amine/connectedhomeip
that referenced
this pull request
Jan 12, 2025
* Add separate knob for TCP server listen enabling. Use a boolean indicator for TCP server enabling in the TCPListenParameters to signal Server enabling during initialization. By default, TCP Server is enabled on the Server side, and disabled on the client/controller side. Add API in TransportMgr to access this setting so that DNS-SD operational advertisements for TCP can be set accordingly. * Add 2 unit tests * Apply suggestions from code review Co-authored-by: Andrei Litvin <[email protected]> --------- Co-authored-by: Andrei Litvin <[email protected]>
pidarped
added a commit
to pidarped/connectedhomeip
that referenced
this pull request
Jan 13, 2025
Address post-merge comments from PR project-chip#36979. Keep original order of raw transports in the TransportMgr tuple because it is part of the public API on the controller side. When setting the TCPServerListen flag in DnssdServer, use the same value as in TcpListenParams directly, instead of fetching from the TransportMgr.
yufengwangca
pushed a commit
that referenced
this pull request
Jan 14, 2025
* Restore original order of transports in TransportMgr. Address post-merge comments from PR #36979. Keep original order of raw transports in the TransportMgr tuple because it is part of the public API on the controller side. When setting the TCPServerListen flag in DnssdServer, use the same value as in TcpListenParams directly, instead of fetching from the TransportMgr. * Address review comments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use a boolean indicator for TCP server enabling in the TCPListenParameters to signal Server enabling during initialization. By default, TCP Server is enabled on the Server side, and disabled on the client/controller side.
Add API in TransportMgr to access this setting so that DNS-SD operational advertisements for TCP can be set accordingly.
Testing
Add 2 unit tests for checking TCP initialization as TCPClient, and both TCPClient and Server.