Enhancement request: getsockname()-style API

[kFYatek]

Description

• Type: Enhancement
• Priority: Major

---

Enhancement

Reason to enhance or problem with existing solution: mbed OS' current socket API does not have any function like getsockname(). This makes it often infeasible to bind on an ephemeral port, because there is no way to check what is the port number after such binding. It might make sense to use when implementing certain protocols such as e.g. FTP, when there might be many concurrent connections so that we want to avoid port number collisions.

Suggested enhancement: Add some API like SocketAddress Socket::getsockname() with semantics similar to a POSIX function of the same name.

Pros: More complete and flexible networking API.

Cons: Required changes would propagate to NetworkStack and nsapi_stack_api_t APIs, possibly requiring modifications to pre-existing first- and third-party network stack implementations.

[0xc0170]

@kjbracey-arm @mikaleppanen Please review

[kjbracey]

Reasonable request - my feeling is that this falls in to the "too advanced for most off-board modules, so could never be totally relied on being available" category. Mind you, a lot of the NSAPI already is in that space. Being able to bind to a port at all is not as common as you'd imagine.

Adding it to the onboard Nanostack & lwIP would be straightforward though. Feel free to submit a patch doing that.

Not quite understanding your use case though - you're using a mixture of stack-assigned ephemeral ports and application-bound ephemeral ports, and want to avoid application-assigned ones colliding with stack-assigned?

Using entirely application-assigned or stack-assigned would avoid that problem. If doing application ephemeral assignment, you'd also need to in principle need to avoid ports from other applications/processes so just knowing your own sockets' ports wouldn't be sufficient.

Can't you just keep retrying bind until you don't get "address in use" (assuming the stack supports port binding)?

[SeppoTakalo]

I'll propose that this feature request is closed, even that it is coming from POSIX standard, for the reasons listed in "Cons" category.

This propagates API changes to Networkstack which would propagate changes to all external WiFi drivers.
Too much refactoring for too little benefits.

[kjbracey]

We can provide a default "not implemented", but it would be like the status callbacks currently are in that support would be patchy, and probably worse, as it may not ever be possible at all on some devices.

[SeppoTakalo]

getpeername() however can easily be implemented now. (and should be supported by all)