[Feature Request] Add vTimerSetTimerID/pvTimerGetTimerID equivalents for sockets.

[karver8]

Is your feature request related to a problem? Please describe.
There is no easy way to locate application data associated with a socket from a socket callback.

Sockets allow the application to set callback functions for various events, e.g. FREERTOS_SO_TCP_RECV_HANDLER which will call a function with the prototype BaseType_t (* FOnTCPReceive_t )( Socket_t xSocket, void * pData, size_t xLength ). However if the same callback function is assigned to multiple sockets, there is no easy way to "identify" the socket using just its handle. You could define a data structure containing sockets paired with their associated objects and search through this, however this is not very efficient.

Describe the solution you'd like
Add vTimerSetTimerID/pvTimerGetTimerID equivalents to the sockets API and add a void * pvSocketID member to the IPTCPSocket_t struct.

These could look like:

• vSocketSetSocketID/pvSocketGetSocketID
• FreeRTOS_setsocketid/FreeRTOS_getsocketid (more in line with the libraries naming style)

Describe alternatives you've considered
A SOCKET_ID option could be added to FreeRTOS_setsockopt(), and the callback prototypes could be modified to include the socket ID. This however ruins backwards compatibility.

[AniruddhaKanhere]

Hello @karver8!

That is quite an interesting feature request. Thank you for bringing this to out attention and thank you for also proposing a solution. The solution you suggest will seem like it would work.
We'll work on this and get back to you. Till that time, if you happen to have any more suggestions on how can we improve the FreeRTOS+TCP library, feel free to open more feature requests.

Thanks again,
Aniruddha

[htibosch]

Hello Jacob,

I agree with Aniruddha that this is an interesting request.

At one point, we already provide the possibility to add a personal object, in an asynchronous DNS lookup:

uint32_t FreeRTOS_gethostbyname_a( const char * pcHostName,
                                   FOnDNSEvent pCallback,
                                   void * pvSearchID,
                                   TickType_t uxTimeout );

When I use it, "pvSearchID" will point to an object in my source code.

I would not add an ID to IPTCPSocket_t, but to FreeRTOS_Socket_t, so that all sockets can have an ID.

What about :

/* Setting an ID. */
CMySocket *socket = new CMySocket();
FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_SET_USER_ID, ( void ) socket, sizeof( void *) );

/* Getting an ID. */
CMySocket *userID = NULL;
FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_GET_USER_ID, ( void )&( userID ), sizeof( void *) );

and if not, I would like the couple: vSocketSetSocketID() / pvSocketGetSocketID(), which is easier to use.

The setsockopt call here above gets confusing when a pointer to a pointer must be passed.

[karver8]

Hello Hein & Aniruddha,

Thanks for the quick feedback!

FreeRTOS_Socket_t is probably the better choice, I was not aware of it when I suggested IPTCPSocket_t.

I think the get/set couple is the best option. I do not see any problem with using FreeRTOS_setsockopt() to set the ID, however I have problems with the "Getting an ID." portion for a few reasons:

1. It would be confusing to "get" a value from something called "setsockopt", especially since nothing is being set. I believe this would also be the first option of this kind added to FreeRTOS_setsockopt().
2. It would be nice to have a dedicated function for reading the ID since it is something that potentially would be called very frequently. The extra overhead added by FreeRTOS_setsockopt() may add up in that case.

I am glad to hear you are considering this change!

Thanks for the awesome library,
Jacob

[htibosch]

As you see, I submitted #546 to implement the two functions.

Thanks for the awesome library

Thank you for the awesome idea to add a Socket-ID :-)

[AniruddhaKanhere]

Hello @karver8 the PR that @htibosch created has been merged.
I shall be closing this PR now. Feel free to open a new issue or reopen this one if you have more suggestions or concerns.

Thanks.