[lwip-devel] wrap rtos queue in lwip socket

[Piero 74]

FOR LWIP - RTOS users

Hi all.

I have a problem and an idea to solve it. I want discuss here about them.

PROBLEM:
i worked with lwip over an rtos.
i have a task which can get data from network - i.e. a tcp socket - or from other task troght rtos queue.
i want to work without blocking call, and i want short latency for data management on this task.
now i dit something like this:

while(1)
____wait on select (100ms timeout) on tcp connection
____if network data packet is present manage it
____wait on Q read (0ms timeut)
____if internal data packet is present manage it

so, in this way, packet from network is managed as soon as possible, data from other task can wait all select timeout if no packet fron net is received

the solution could be using socket for BOTH, network data and data from queue, and do something like this:

while(1)
____wait on select (100ms timeout) on tcp connection AND queue
____if network data packet is present manage it
____if internal data packet is present manage it


I see how lwip code implements socket:

1. lwip_socket create a socket But this function is splitted:
_____create netconn
_____i = alloc_socket(conn);
2. select unlock itself, when lwip_selscan function finds, in a socket set in fd_set,  lastdata field OR rcvevent field OR sendevent field is change

my idea is:

1. function create_socket_queue
____create a RTOS queue
____call alloc_socket(conn), using queue handle as parameter queu, forcing a cast to netconn
2. function senddata_socket_queue(int s)
____call get_socket(int s)
____get conn parameter, force cast to queue handle and send data to it
____increment rcvevent (or sendevent or both)
3. function receivedata_socketqueue
____call get_socket(int s)
____get conn parameter, force cast to queue handle and try to receive data from it
____decrement rcvevent (or sendevent or both) if data was present

obviously, using this functions with network socket will be an error, and using queue_socket with conventional socket function will be an error
A workaround, could be to build a new structure like this:

struct typedef extended_socket
{
int s; // socket id
int type; // can be NET_SOCK or Q_SOCK
}

and wrap all socket function using extended_socket as parameter, and type field as switch value for calling diferent version of function


what is your opinion about this idea?

bye,
Piero