Experimental Physics and
Industrial Control System

Torsten Bögershausen <[email protected]> · Tue, 27 Feb 2018 21:36:48 +0100

On 23/02/18 15:17, Daykin, Evan wrote:

Hi Mark,

Thanks for the reply. We are using asyn 4.33-2 and Stream 2.6-3. The protocol

file has a ReplyTimeout of 2000ms.

Sorry if this is the wrong question, but what is asyn 4.33-2 ?
"git tag" mentions R4-33, not "-2".

And to answer the other question:

>Here's something interesting: asyn behaves correctly for us *only* when the

>client application is killed with SIGKILL, rather than SIGTERM. This results

>in TCP retransmissions and/or refused connections, then normal operation

after >a short while. Is it possible asyn is [un]intentionally not retrying

the >connection if it is closed gracefully?

The code that I see producing "Read from broken connection" is this:

 /* If recv() returns 0 on a SOCK_STREAM (TCP) socket, the connection has

closed */

    if ((thisRead == 0) && (tty->socketType == SOCK_STREAM)) {
        epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize,
                      "%s connection closed",
                      tty->IPDeviceName);
        closeConnection(pasynUser,tty,"Read from broken connection");

----------
And then
closeConnection(asynUser *pasynUser,ttyController_t *tty,const char *why)
{
    asynPrint(pasynUser, ASYN_TRACE_FLOW,

 "Close %s connection (fd %d): %s\n", tty->IPDeviceName, tty->fd,

why);

So from asyn everything seems to be OK.

It seems that the problem described here:
>2018/02/23 09:51:47.089 test-rf-dcu-n0001.cts:5001 read.
>The last line then repeats rapidly forever.

is caused by the caller into asyn, which is streamdevice ?
There seem to be some improvements in streamdevice,
but I am not familiar with the code.

Dirk, does there ring a bell  ?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System