Experimental Physics and
Industrial Control System

Hi Jignesh,

 

-          In my case for write, I was trying dummy write with 0 length and it was not detecting the broken channel

(I assumed that it will be supported as per the Release Notes :  Release 4-5 “Serial, TCP/UDP/IP :---Handle 0-length write requests” ) I think write with 0 packet is valid situation in case of socket send method..?

 

I believe the Release Notes meant that a 0-length write does not return an error.  However, in the current implementation it does not actually send a message:

 

static asynStatus writeIt(void *drvPvt, asynUser *pasynUser,

    const char *data, size_t numchars,size_t *nbytesTransfered)

{

    ttyController_t *tty = (ttyController_t *)drvPvt;

    int thisWrite;

    asynStatus status = asynSuccess;

    int writePollmsec;

    int epicsTimeStatus;

    epicsTimeStamp startTime;

    epicsTimeStamp endTime;

    int haveStartTime;

 

    assert(tty);

    asynPrint(pasynUser, ASYN_TRACE_FLOW,

              "%s write.\n", tty->IPDeviceName);

    asynPrintIO(pasynUser, ASYN_TRACEIO_DRIVER, data, numchars,

                "%s write %lu\n", tty->IPDeviceName, (unsigned long)numchars);

    *nbytesTransfered = 0;

    if (tty->fd == INVALID_SOCKET) {

        if (tty->flags & FLAG_CONNECT_PER_TRANSACTION) {

            if ((status = connectIt(drvPvt, pasynUser)) != asynSuccess)

                return status;

        }

        else {

            epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize,

                          "%s disconnected:", tty->IPDeviceName);

            return asynError;

        }

    }

    if (numchars == 0)

        return asynSuccess;

…

 

So if numchars==0 it just returns asynSuccess without doing anything as long as it thinks the socket is connected (ttype->fd != INVALID_SOCKET.  And tty->fd will only be set to INVALID_SOCKET if it tries to send a message and fails.

 

I don’t know what the rules are about sending a 0-length message with send().  Is it allowed, and is the behavior well-defined for all platforms?  What you are trying to do is to send a 0-length message to determine if the socket is still connected.  I will defer to Eric or others on this.

 

> So I hope I am able to explain the scenario,

> one more thing this read and write with some dummy packet length are able to detect the broken connection if we keep PLC in STOP mode manually,

> but this method doesn’t detect the broken connection if I disconnect the network cable from PLC after successful connection.

 

How long did you wait after disconnecting the network cable to see if asyn would report isConnected()=false?  The timeout can take a long time (5 minutes?) on Linux.

 

> Though in all cases, reconnection is established automatically by asyn.

 

That’s good.

 

Mark