#177 Should a UDP receive socket for MD be closed in case of TRDP_BLOCK_ERR

[Joachim Lillich]

The problem is located in the trdp_mdSend function.
The test scenario is:

1. create an md listener
2. send a request to the listener
3. send a reply: when sending the reply, a socket error occurs leading to a TRDP_BLOCK_ERR.

This error is handled by the following code

                        else
                        {
                            MD_ELE_T *iterMD_find = NULL;

                            /* search for existing session */
                            for (iterMD_find = appHandle->pMDSndQueue;
                                 iterMD_find != NULL;
                                 iterMD_find = iterMD_find->pNext)
                            {
                                if (iterMD_find->socketIdx == iterMD->socketIdx)
                                {
                                    iterMD_find->morituri = TRUE;

                                    /* Execute callback for each session */
                                    if (iterMD_find->pfCbFunction != NULL)
                                    {
                                        trdp_mdInvokeCallback(iterMD_find, appHandle, TRDP_TIMEOUT_ERR);
                                    }
                                }
                            }

                            /* Close the socket */
                            appHandle->iface[iterMD->socketIdx].tcpParams.morituri = TRUE;
                        }

The socket is marked to be closed but the listener callback is not invoke since there is no iteration done over the pMDRcvQueue queue!
When the socket is closed the listener is not informed that it is out of order due to the missing receive socket.

But do you really need to close the listener socket?

[Armin-Hagen Weiss]

A reply needs to be sent via tlm_reply(). This calls trdp_mdReply() and not trdp_mdSend() !!!

[Joachim Lillich]

Yes, the reply is sent with the interface function tlm_reply().
And trdp_reply() does not directly send the reply, it puts it into a queue.
This queue is processed by tlc_process() which calls trdp_send().

And here the problem arises:
When it is a caller socket it is OK to close that socket because it is not needed any more.
When it is a receiving socket is not OK to close that socket because we loose the ability to receive telegrams.

[Armin-Hagen Weiss]

Thanks for clarification.

[mike]

It seems evident, that the closing of a socket needs to be moved into the send queue iteration. Having it outside the iteration will lead to "close anyway", which is not desirable.
For the receiver side it is really a point not to close a receiver socket at all. Though this needs some consideration.

[Joachim Lillich]

You could add an interation over the receive queue. In this case the listener can be informed that something bad happened to its socket.

[mike]

Yes, agreed - some information would be a benefit.

[mike]

moved socket deletion to the iteration loop leaving the listen socket notification open [r1698]

[mike]

the notification for listener sockets is done differently: in trdp_mdCheckTimeouts the function trdp_mdTimeOutStateHandler determines the return codes and marks the queue elements accordingly as morituri