Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: TCP connection status : drvAsynIPPort
From: Eric Norum <wenorum@lbl.gov>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Patel Jignesh <Jignesh.Patel@iter.org>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 8 Oct 2014 11:58:51 -0700
I presume the thinking was, "TCP is stream oriented, so a write of 0 bytes should not cause the reader to return anything — so don't bother even attempting the write”.  Does a 0-length write actually test the channel?
Now that ASYN supports UDP, in which a 0-length send actually shows up as a 0-length receive, might be another argument against the code in question.


I’ll tactfully refrain from my traditional rant about TCP being the wrong choice for control communication…..

On Oct 8, 2014, at 11:01 AM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

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
 

-- 
Eric Norum
wenorum@lbl.gov


Replies:
Re: TCP connection status : drvAsynIPPort J. Lewis Muir
References:
TCP connection status : drvAsynIPPort Patel Jignesh
RE: TCP connection status : drvAsynIPPort Mark Rivers
RE: TCP connection status : drvAsynIPPort Patel Jignesh
RE: TCP connection status : drvAsynIPPort Mark Rivers

Navigate by Date:
Prev: RE: TCP connection status : drvAsynIPPort Mark Rivers
Next: Re: TCP connection status : drvAsynIPPort J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: TCP connection status : drvAsynIPPort Mark Rivers
Next: Re: TCP connection status : drvAsynIPPort J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·