EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: PV Access protocol Destroy Channel swaps cid, sid
From: "Kasemir, Kay via Core-talk" <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Tue, 21 May 2019 13:36:51 +0000
Hi:

The PV Access protocol documentation for the Destroy channel (0x08) message, https://github.com/epics-base/pvAccessCPP/wiki/protocol#destroy-channel-0x08,  claims that the format is CID first, SID second:

struct destroyChannelRequest {
    int clientChannelID;
    int serverChannelID;
};

struct destroyChannelResponse {
    int clientChannelID;
    int serverChannelID;
};

The server implementations are in fact the other way round.
Both 
https://github.com/epics-base/pvAccessCPP/blob/master/src/server/responseHandlers.cpp#L984 
and 
https://github.com/epics-base/epicsCoreJava/blob/master/pvAccessJava/src/org/epics/pvaccess/server/impl/remote/handlers/DestroyChannelHandler.java#L50

basically have this:
    transport->ensureData(8);
    const pvAccessID sid = payloadBuffer->getInt();
    const pvAccessID cid = payloadBuffer->getInt();

The servers also send a reply with SID first, followed by CID.


The client, however, follows the protocol documentation, and takes the first ID to be the CID,
https://github.com/epics-base/pvAccessCPP/blob/master/src/remoteClient/clientContextImpl.cpp#L2934 :

        pvAccessID cid = payloadBuffer->getInt();
     /*pvAccessID sid =*/ payloadBuffer->getInt();


==> Client and server destroy different channels, which results in "Trying to destroy a channel that no longer exists (SID: 4, CID 3, client: 127.0.0.1:51886)" messages and dropped data.

My suggestion:

Update protocol to what the servers are actually do, i.e. 

struct destroyChannelRequest {
    int serverChannelID;
    int clientChannelID;
};

struct destroyChannelResponse {
    int serverChannelID;
    int clientChannelID;
};

No change to already deployed servers.
Clients need to be fixed.

Thanks,
Kay


Navigate by Date:
Prev: Build failed: EPICS Base base-7.0-399 AppVeyor via Core-talk
Next: Build failed in Jenkins: epics-base-7.0-win64 #29 APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Build failed: EPICS Base base-7.0-399 AppVeyor via Core-talk
Next: Build failed in Jenkins: epics-base-7.0-win64 #29 APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 21 May 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·