Skip to content
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

[coap] resolve the issue where pending requests cannot be matched with their corresponding response messages with UDP port #10269

Closed

Conversation

ZhangLe2016
Copy link
Contributor

In function FindRelatedRequest, parameter aMessageInfo represents the message received from the peer device. When iterating through pending requests, the outgoing message's destination address and port should match the source address and port of the received message instead of the destination address and port of the received message.

their corresponding response messages

In function FindRelatedRequest, parameter aMessageInfo represents the
message received from the peer device. When iterating through pending
requests, the outgoing message's destination address and port should
match the source address and port of the received message instead of the
destination address and port of the received message.
Copy link

size-report bot commented May 18, 2024

Size Report of OpenThread

Merging #10269 into main(6444157).

name branch text data bss total
ot-cli-ftd main 467040 856 66364 534260
#10269 467040 856 66364 534260
+/- 0 0 0 0
ot-ncp-ftd main 435900 760 61576 498236
#10269 435900 760 61576 498236
+/- 0 0 0 0
libopenthread-ftd.a main 236166 95 40310 276571
#10269 236166 95 40310 276571
+/- 0 0 0 0
libopenthread-cli-ftd.a main 57533 0 8075 65608
#10269 57533 0 8075 65608
+/- 0 0 0 0
libopenthread-ncp-ftd.a main 31863 0 5916 37779
#10269 31863 0 5916 37779
+/- 0 0 0 0
ot-cli-mtd main 364520 760 51220 416500
#10269 364520 760 51220 416500
+/- 0 0 0 0
ot-ncp-mtd main 347060 760 46448 394268
#10269 347060 760 46448 394268
+/- 0 0 0 0
libopenthread-mtd.a main 158165 0 25182 183347
#10269 158165 0 25182 183347
+/- 0 0 0 0
libopenthread-cli-mtd.a main 39756 0 8059 47815
#10269 39756 0 8059 47815
+/- 0 0 0 0
libopenthread-ncp-mtd.a main 24743 0 5916 30659
#10269 24743 0 5916 30659
+/- 0 0 0 0
ot-cli-ftd-br main 550704 864 131204 682772
#10269 550704 864 131204 682772
+/- 0 0 0 0
libopenthread-ftd-br.a main 324624 100 105126 429850
#10269 324624 100 105126 429850
+/- 0 0 0 0
libopenthread-cli-ftd-br.a main 71320 0 8099 79419
#10269 71320 0 8099 79419
+/- 0 0 0 0
ot-rcp main 62216 564 20604 83384
#10269 62216 564 20604 83384
+/- 0 0 0 0
libopenthread-rcp.a main 9542 0 5052 14594
#10269 9542 0 5052 14594
+/- 0 0 0 0
libopenthread-radio.a main 18870 0 214 19084
#10269 18870 0 214 19084
+/- 0 0 0 0

aMetadata.mDestinationAddress.IsMulticast() ||
aMetadata.mDestinationAddress.GetIid().IsAnycastLocator()) &&
(aMetadata.mDestinationPort == aMessageInfo.GetPeerPort()))
(aMetadata.mDestinationPort == aMessageInfo.GetSockPort()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the existing code is correct. It leverages MessageInfo, which is applicable to both transmitting (tx) and receiving (rx) messages, dynamically adjusting the interpretation of "peer" and "local".

Within a MessageInfo the peer address/port consistently refers to the other device involved in the communication (either the source we received the message from or the destination we are sending it to).

Specifically:

  • For a received message, GetPeerAddress() will be the source address (sender's address).
  • For a sent message, GetPeerAddress() will be the destination address.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ZhangLe2016 I noticed you've changed the PR to only use GetSockPort(). However, the earlier comment applies to GetPeerPort() same was as GetPeerAddress(). The existing code using the peer's port and address is the correct behavior.

Considering this, suggest closing this PR?

@ZhangLe2016 ZhangLe2016 changed the title [coap] resolve the issue where pending requests cannot be matched with their corresponding response messages [coap] resolve the issue where pending requests cannot be matched with their corresponding response messages with UDP port May 18, 2024
their corresponding response messages with UDP port

In function FindRelatedRequest, parameter aMessageInfo represents the
message received from the peer device. When iterating through pending
requests, the outgoing message's destination port should match the
destination port of the received message such as :MM 61631.
@ZhangLe2016
Copy link
Contributor Author

@abtink Thanks a lot for

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants