[En-Nut-Discussion] NutTcpAccept blocks the tread

[Ulrich Prinz]

Hi!

I had that problem on a serial interface protocol... Establishing 
communication, doing a handshake and setup and then run a protocol 
everything with different timings and second and third part with 
timeout, first one without...

I solved it with a simple thing:
I wrote a minimalistic thread waiting for an event on th serial line. If 
the event happened, the thread does an initial handshake and creates the 
second thread and terminates itself directly after.
The second thread initiates telegrams and creates a third thread, 
decoding the telegrams. If the third thread detects communication 
problems, it terminates itself and the second thread tries to recover. 
If that fails, the second thread starts the first one and terminates itself.
Works wonderful!

Now to your problem:
How if you write a small thread for waiting for a tcp connection. You 
can start this thread several times, giving different parameters 
regarding the ports and interfaces to serve. You hand over a parameter 
pointing to the stream too.

Then you write a second thread, serving the data when an connection has 
been established. This thread can have timeout handling and the other 
things you like. The state-machine in the main loop can detect if the 
thread has a connection or not by a variable or something.

Now, I would not start the second thread as I do not see, why one single 
state machine does everything, but if you like, start 5 of the first and 
5 of the second threads.

If a connection is accepted, the first type of threads detects it, 
accepts the connection and does a NutEventPost on the related 
data-thread. While normally a timeout will result in NutEventWait() == 
-1, now it will return 0 and you know that you have been waked by 
incoming data, so handle it.

I would have started the data-threads in the accept-threads and handed 
over the needed pointers to the stream as a parameter. You need to 
define a message-box or use some global variables for that. Both should 
work and does not need a rework of the network system.

The accept-threads can also get some more timeout handling. If the 
data-threads see, that a connection is closed, they can do a 
NutEventPost() on the accept-threads. But that could lead to a stuck 
thread if there is an unclean connection abort. So the accept threads 
could check some counters or so to assure that the corresponding 
data-thread is working well. If they get awake because NutEventWait() 
returns -1 they check and handle erroneous conditions, if returned 0 the 
await a new connection.

If you change to my implementation, the accept-threads will create 
corresponding data-threads and vice versa. The main loop will check if 
either accept- or data-thread exists and works well. If not it will 
reboot or try to kill the threads ( never checked if that is possible 
with Nut/OS) and restart them.

Regards,
Ulrich

Nathan Moore schrieb:
> Hey Harald,
> 
>> Considered, that NutTcpPassiveOpenEvent had been changed following your
>> suggestion, the application will use the following pseudo code:
>>
>> for (;;) {
>>  CreateSocket();
>>  SocketOption(Set read timeout);
>>  while (NutTcpAccept()) {
>>    /* Timout, do something else,
>>    ** but do not sleep. */
>>  }
>>  /* Handle the connection. */
>>  ...
>>  /* Finally */
>>  DestroySocket();
>> }
>>
>> Is that what you meant?
> 
> 
> Yes.  It could check a variable or something and never open the window of
> not listening to that port.
> If it did sleep there it would still work, but would introduce the
> possibility that you wouldn't be listening for a moment..
> 
> 
> Nathan
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion