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

New feature: send/recv message implementation added to network stack #14847

Conversation

tymoteuszblochmobica
Copy link
Contributor

Summary of changes

Mbed doesn't support ancillary data sending receive during sendto / recvfrom.
New interface added to Network interface, LWIP Stack implementation and necessary stubs for Cellular and Nanostack.

Impact of changes

Need for rebuild libraries and applications using netsocket.

Migration actions required

None

Documentation

None


Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@pan-
@kjbracey-arm

@ciarmcom ciarmcom requested review from pan- and a team June 30, 2021 19:30
@ciarmcom
Copy link
Member

@tymoteuszblochmobica, thank you for your changes.
@pan- @ARMmbed/mbed-os-connectivity @ARMmbed/mbed-os-mesh @ARMmbed/mbed-os-maintainers please review.

pan-
pan- previously requested changes Jun 30, 2021
Copy link
Member

@pan- pan- left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, I think it would be good to update all stacks implementation so their sendto/recvfrom calls into sendmsg/recvmsg. That would allow the socket level to do the same.

I think a helper to build the control options will be needed to but it might not be necessary yet as just pkt_info is available.

connectivity/lwipstack/include/lwipstack/LWIPStack.h Outdated Show resolved Hide resolved
connectivity/lwipstack/include/lwipstack/lwipopts.h Outdated Show resolved Hide resolved
connectivity/lwipstack/source/LWIPStack.cpp Show resolved Hide resolved
connectivity/lwipstack/source/LWIPStack.cpp Outdated Show resolved Hide resolved
connectivity/netsocket/include/netsocket/MsgHeader.h Outdated Show resolved Hide resolved
typedef struct nsapi_pktinfo {
nsapi_msghdr_t hdr; /* Header identifying the message control structure */
nsapi_addr_t ipi_addr; /* Address associated with the packet */
int ipi_ifindex; /* Interface associated with the packet */
Copy link
Member

Choose a reason for hiding this comment

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

This will return the internal interface index. I believe we should return/accept a pointer to a NetworkInterface. Some translation must be done in the NetworkStack implementation to make that possible.

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe this chunk of API is currently C... That might be rather intractible.

For starters, we do need some way of mapping IDs to/from NetworkInterfaces. I think that is currently missing - we've hit this before. A comparator is the multicast group membership sockopt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -145,6 +145,14 @@ class TCPSocket : public InternetSocket {
nsapi_size_or_error_t recvfrom(SocketAddress *address,
void *data, nsapi_size_t size) override;

virtual nsapi_size_or_error_t sendmsg(const SocketAddress &address,
Copy link
Contributor

Choose a reason for hiding this comment

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

Existing code (and recommended style) omits virtual with override.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

typedef struct nsapi_pktinfo {
nsapi_msghdr_t hdr; /* Header identifying the message control structure */
nsapi_addr_t ipi_addr; /* Address associated with the packet */
int ipi_ifindex; /* Interface associated with the packet */
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe this chunk of API is currently C... That might be rather intractible.

For starters, we do need some way of mapping IDs to/from NetworkInterfaces. I think that is currently missing - we've hit this before. A comparator is the multicast group membership sockopt.

* @return Number of sent bytes on success, negative error
* code on failure
*/
virtual nsapi_size_or_error_t socket_sendmsg(nsapi_socket_t handle, const SocketAddress &address,
Copy link
Contributor

Choose a reason for hiding this comment

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

This isn't terribly close to POSIX sendmsg, it's an API halfway house between sendto and sendmsg. Maybe it should have a different name like sendto_ancillary?

Copy link
Member

Choose a reason for hiding this comment

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

I agree, it's between sendto and sendmsg. I don't think we want a full blown sendmsg/recvmsg as it requires an extra buffer if there is more than one buffer submitted in the iovec field. Adding ancillary would talk to the one that are used to the POSIX API but for newcomers I always find it confusing. These are control flags, not just random additional/meta data.

On the other hand I'm not sure what a good name would be.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep, the iovec is nice-to-have occasionally, but implementing it as emulation on top of non-vector stuff is counter-productive. Most underlying stacks will not support it.

Maybe _control makes sense, as that is the actual name of the field in the struct msghdr.

virtual nsapi_size_or_error_t socket_recvmsg(nsapi_socket_t handle, SocketAddress *address,
void *data, nsapi_size_t size,
nsapi_msghdr_t *control, nsapi_size_t control_size) = 0;

Copy link
Contributor

Choose a reason for hiding this comment

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

This could have a default implementation that passes onto recvfrom if control is NULL, otherwise returns "not supported".

Indeed, I think a default implementation is needed to not be a breaking API change for all existing NetworkStack implementors. Their stacks (including all those little Wifi modules) won't compile.

@tymoteuszblochmobica tymoteuszblochmobica force-pushed the SendRecvMessage branch 3 times, most recently from 600839b to a97b2e5 Compare July 5, 2021 12:07
@tymoteuszblochmobica tymoteuszblochmobica force-pushed the SendRecvMessage branch 2 times, most recently from 5214725 to 8b4d3f1 Compare July 8, 2021 22:36
@mergify
Copy link

mergify bot commented Jul 8, 2021

This PR cannot be merged due to conflicts. Please rebase to resolve them.

@ciarmcom
Copy link
Member

This pull request has automatically been marked as stale because it has had no recent activity. @tymoteuszblochmobica, please carry out any necessary work to get the changes merged. Thank you for your contributions.

@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Jul 23, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Aug 1, 2021
@ciarmcom ciarmcom added the stale Stale Pull Request label Aug 8, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented Aug 12, 2021

@tymoteuszblochmobica Travis failed - unit tests. Please review

@pan- Can you review after the last update?

@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Aug 13, 2021
@pan-
Copy link
Member

pan- commented Aug 19, 2021

@0xc0170 I'm continuing this PR from here.

@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Aug 20, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Aug 27, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Sep 3, 2021
@mergify
Copy link

mergify bot commented Sep 9, 2021

This PR cannot be merged due to conflicts. Please rebase to resolve them.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 9, 2021

#15040 merged, closing this one.

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.

5 participants