LWIP socket creation issue

[Altera_Forum]

LWIP socket creation issue 

 I currently have implemented an algorithm that allows two separate devices (using the same code) to create and maintain a socket that goes something like:   TaskA { while (true) { If(Connection == false)  Start Task B  Wait X seconds  If (Connection == false)  Shutdown Socket  Delete Task B } }  Task B { socket() // Create socket connect() // try to connect to external device (be the client)   // Be the server)  If (ConnectionFailed) Bind() Listen() Accept() // blocks here until incoming req or task B is deleted by Task A  // we will only get here if we accept an incoming socket request Connection = true }  This mechanism allows either device to be server or client depending on who gets booted first or if the socket is lost, they will search for each other and recreate the socket.  All is well until the 14th time task A creates task B, the call to listen() fails  On closer examination the failure results from the follow sequence of calls:  Listen() // in my app  lwip_listen() // in sockets.c  netconn_listen() // in api_lib.c   if(conn->acceptmbox == SYS_MBOX_NULL) {  conn->acceptmbox = sys_mbox_new();  if (conn->acceptmbox == SYS_MBOX_NULL) {  return ERR_MEM;  }  …. The “return ERR_MEM†is being executed, based on a failure with the sys_mbox_new() call. The sys_mbox_new() makes a call to OSQCreate() which is failing, this uCOS call creates a message queue.    Has anyone come across this issue? If this is a stack issue, I’d like to avoid just increasing the size, this would just be delaying the on set of the problem.   Aiden

[Altera_Forum]

Try increasing LWIP_MAX_QS in include/arch/sys_arch.h, from 10 to something like 60... 

 This seems to limit the total number of active sockets in some way. I don&#39;t know the actual details.  Let me know if that fixes it - Rugbybloke may also be interested... http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif    - Roddy

[Altera_Forum]

As per Roddy&#39;s suggestion I tried increasing LWIP_MAX_QS in include/arch/sys_arch.h to 60 but I&#39;m afraid no joy! I still have the listen() failure at the same point in time 

 Aiden

[Altera_Forum]

I&#39;ve not come across this problem, but you could try increasing the number of MicroC OS II Queues. If you right click on your system library project and select RTOS options. Expand the MicroC/OS-II in the left pane select Queues and you can change the number of queues. 

 As you rightly point out this could just be delaying the onset of the problem. Are all the previous sockets which have been created being closed, or are you just running out of resources?

[Altera_Forum]

Which call are you using to create the new tasks? I believe you can&#39;t really use the "sys_thread_new" function to create threads which are subsequently terminated. 

  - Roddy

[Altera_Forum]

>Are all the previous sockets which have been created being closed, or are you just running >out of resources? 

 The socket is being closed each time after an attempted connection i.e. task A is shutdown the socted if Task B failed to make an out going connection or failed to accept an incoming connection. I am using the close() and have also tried shutdown() (which currently just implements close()). So each time a socket is created it is closed before the next attempt to create another.  >Which call are you using to create the new tasks? I believe you can&#39;t really use the >"sys_thread_new" function to create threads which are subsequently terminated.  I am currently using:  sys_thread_new() to create task A (which is always active) and OSTaskCreateExt() to create task B from task A (I am using OSTaskDel() to delete task B from task A)  Aiden

[Altera_Forum]

Did you try increasing the number of Queues as I suggested? 

 Also you have to create threads using sys_thread_new if you wish to use sockets in those threads.

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  Also you have to create threads using sys_thread_new if you wish to use sockets in those threads.[/b]  --- Quote End ---    I&#39;m not sure I understand why you say this - what is the specific issue? IIRC, sys_thread_new is inappropriate for any task which terminates rather than loops forever - and the easiest way of implementing TCP/IP servers is to have the listen thread spawn new processing threads as required, which then die when the socket connection is closed.   - Roddy

[Altera_Forum]

The issue is all to do with the sys_arch_timeouts function which handles general system timeouts. It is vital that the priority of the all the socket using threads lie between 0 and LWIP_MAX_TASKS. You can handle this manually if you wish.

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  Posted on Nov 19 2004, 05:46 AM --------------------------------------------------------------------------------  The issue is all to do with the sys_arch_timeouts function which handles general system timeouts. It is vital that the priority of the all the socket using threads lie between 0 and LWIP_MAX_TASKS.[/b]  --- Quote End ---    Understood - but as LWIP_MAX_TASKS is set to OS_LOWEST_PRIO, you can&#39;t create tasks with priorities outside that range anyway.   - Roddy

[Altera_Forum]

>Did you try increasing the number of Queues as I suggested? 

 Yes sir I did! But as I expected it just delays the onset of the problem.   > The issue is all to do with the sys_arch_timeouts function which handles general system > > timeouts. It is vital that the priority of the all the socket using threads lie between 0 and > > LWIP_MAX_TASKS. You can handle this manually if you wish.  I have confirmed that all tasks accessing the socket have priorities between 0 and LWIP_MAX_TASKS  Aiden

[Altera_Forum]

Be sure to call OSQDel when you are finished with a queue so that when that task boots again it wont try to allocate more and more queues.