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