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 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024	Index	1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: asyn IP server port driver with streamDevice
From:	Rod Nussbaumer <[email protected]>
To:	Mark Rivers <[email protected]>, EPICS Mailing list <[email protected]>
Date:	Thu, 25 Jan 2018 17:39:48 +0000

Thanks for the detailed description. I look forward to hearing of the new version.

--- rod.

From: Mark Rivers <[email protected]>
Sent: Thursday, January 25, 2018 9:28 AM
To: Rod Nussbaumer; EPICS Mailing list
Subject: RE: asyn IP server port driver with streamDevice

Hi Rod,

The existing implementation of drvAsynIPServer port works as follows, as documented in https://epics.anl.gov/modules/soft/asyn/R4-32/asynDriver.html

***************************************

This driver implements the asynOctet interface. The only methods it supports are registerInterruptUser and cancelInterruptUser. Calling the other asynOctet methods will result in an error. The following happens when a new connection is received on the port specified in drvAsynIPServerPortConfigure:

If there are no registered asyn clients (who have called registerInterruptUser on the asynOctet interface of the listener port) then the incoming connection is immediately closed, since there are no IP servers available to service it. If there is at least one registered client, then the following steps are executed.
The list of drvAsynIPPort ports that this listener thread has created is searched to see if there is an existing port that is currently disconnected because the remote IP client disconnected.
If there is an existing disconnected port, then it is reconnected with the file descriptor from the new IP connection.
If there is no available existing port, then a new one is created by calling drvAsynIPPortConfigure. The name of the new port is of the form portName:1, portName:2, etc., where portName is the name of the listener port.
The asynTraceMask and asynTraceIOMask of the newly connected port are set to the current values of the listener thread port. This makes it possible to trace the early stages of execution of the callbacks to the registered clients, before one could enable tracing at iocsh.
All registered asyn clients (who have called registerInterruptUser on the asynOctet interface of the listener port) are called back with the name of the newly connected port.
The clients then will connect to this new asyn port and perform I/O using the asynOctet methods.

***************************************

So the way it works is that drvAsynIPServer port creates a thread that listens for incoming connections on the specified TCP port. The first time a connection is received it creates a drvAsynIPPort that is connected to the file description for that connection. It is this drvAsynIPPort that you need to pass to StreamDevice.

The problem is that in the current implementation that devAsynIPPort is only created when the first connection is received. This is not what you want, because typically that won’t happen until after iocInit, when it is too late for your application. You need the port to exist before iocInit the StreamDevice INP and OUT links will connect at iocInit.

Here is a simple demonstration of the existing implementation using the testAsynIPServerApp application in asyn. It creates a drvAsynIPServer port called P5001 listening on TCP port 5001. It accepts a single incoming connection.

corvette:asyn/iocBoot/ioctestIPServer>../../bin/linux-x86_64/testIPServer st.cmd.test

< envPaths

epicsEnvSet("IOC","ioctestIPServer")

epicsEnvSet("TOP","/home/epics/devel/asyn-4-33")

epicsEnvSet("SUPPORT","/corvette/home/epics/devel")

epicsEnvSet("IPAC","/corvette/home/epics/devel/ipac-2-14")

epicsEnvSet("SNCSEQ","/corvette/home/epics/devel/seq-2-2-5")

epicsEnvSet("EPICS_BASE","/corvette/usr/local/epics-devel/base-7.0.1")

dbLoadDatabase("../../dbd/testIPServer.dbd")

testIPServer_registerRecordDeviceDriver(pdbbase)

#The following command starts a server on port 5001

drvAsynIPServerPortConfigure("P5001","localhost:5001",1,0,0,0)

serverPort: 5001

#asynSetTraceFile("P5001",-1,"")

asynSetTraceIOMask("P5001",-1,0x2)

#asynSetTraceMask("P5001",-1,0xff)

iocInit()

Starting iocInit

############################################################################

## EPICS R7.0.1.1

## EPICS Base built Jan 3 2018

############################################################################

iocRun: All initialization complete

ipEchoServer("P5001")

epics>

I now run asynReport to show all asynPortDrivers in this IOC. Note that there is only 1, P5001.

epics> asynReport 1

P5001 multiDevice:No canBlock:Yes autoConnect:Yes

enabled:Yes connected:Yes numberConnects 1

nDevices 0 nQueued 0 blocked:No

asynManagerLock:No synchronousLock:No

exceptionActive:No exceptionUsers 0 exceptionNotifys 0

traceMask:0x1 traceIOMask:0x2 traceInfoMask:0x1

Port P5001: Connected

fd: 4

Max. clients: 1

Num. clients: 0

In another terminal session I executed the command “ telnet localhost 5001”. That caused a new drvAsynIPPort port (P5001:1) to be created, as shown by asynReport.

epics> asynReport 1

P5001 multiDevice:No canBlock:Yes autoConnect:Yes

enabled:Yes connected:Yes numberConnects 1

nDevices 0 nQueued 0 blocked:No

asynManagerLock:No synchronousLock:No

exceptionActive:No exceptionUsers 0 exceptionNotifys 0

traceMask:0x1 traceIOMask:0x2 traceInfoMask:0x1

Port P5001: Connected

fd: 4

Max. clients: 1

Num. clients: 1

P5001:1 multiDevice:No canBlock:Yes autoConnect:No

enabled:Yes connected:Yes numberConnects 1

nDevices 0 nQueued 0 blocked:No

asynManagerLock:No synchronousLock:Yes

exceptionActive:No exceptionUsers 1 exceptionNotifys 0

traceMask:0x1 traceIOMask:0x2 traceInfoMask:0x1

Port localhost:5001: Connected

StreamDevice could now connect to that port and it should do what you want. But as I said above, it is too late, that port needed to exist before iocInit.

I think the solution is simple. drvAsynIPServer port should be changed so that it creates the drvAsynIPPorts in its constructor, before any connections are made. It will be in the “disconnected” state. Once a connection comes in it will connect to that file description. I think this change makes a lot of sense, since it makes things simpler.

I will make this change and push to a branch on Github where you can test it. Once we are happy I will poll tech-talk to see if anyone is using drvAsynIPServerPort and would object to this change. It would require a small change to their application. If there is no objection I will replace drvAsynIPServerPort. If there is objection I will call the new driver something else.

Mark

From: Mark Rivers
Sent: Tuesday, January 23, 2018 11:11 PM
To: Rod Nussbaumer <[email protected]>; EPICS Mailing list <[email protected]>
Subject: Re: asyn IP server port driver with streamDevice

Hi Rod,

I’ve looked at this more closely, and my initial answer is incorrect. This is not how it works. I need to think about how it could work for your use case.

Mark

Sent from my iPhone

On Jan 23, 2018, at 6:46 PM, Mark Rivers <[email protected]> wrote:

Hi Rod,

I have not tested what you are trying to do, but I think it should work. You are just missing one step.

1)      You need to create a drvAsynIPServer port to listen for incoming connections. You did this.

2)      You then need to create a normal client drvAsynIPort that connects to the server created in step 1.

3)      Stream device connects to the client port, not to the server port.

For example:

drvAsynIPServerPortConfigure("CYC_server", "localhost:9999",10,1,1)

drvAsynIPPortConfigure("CYC_client", "localhost:9999",0,0,0)

dbLoadRecords( "/mnt/icfileserv/usr1/common/db/ccs2epics01.db", PORT="CYC_client" )

Give it a try and let me know if it does or does not work.

Mark

From: [email protected] [mailto:[email protected]] On Behalf Of Rod Nussbaumer
Sent: Tuesday, January 23, 2018 5:43 PM
To: EPICS Mailing list <[email protected]>
Subject: asyn IP server port driver with streamDevice

Hi All.

I'm trying to do something that seems to have many moving pieces, but I think it should work, with a little guidance here. I have database and accompanying protocols that are attempting to use the I/O Intr methods documented in the streamDevice docs, which say that I can have a series of records receive the input stream to attempt a matching scan. I'm doing this with an async port that is a TCP Server port. The port configuration seems to work; I can make a telnet connection to it. I was hoping that I could type the text matching the streamDevice 'in' protocol, and that the record attached to the protocol would process the input. I don't seem to be getting any data through the asyn TCP server port. The record doesn't process (stays UDF). Moreover, the asynReport data always stays at 0 bytes sent, and 0 bytes received.

I'm using the latest streamDevice from github (hard to figure out version numbers from there) and asyn4-22 with EPICS 3.14.12.2

Following are some excerpts from startup script, IOC DB and streamDevice protocol files.

-------------------------< IOC startup script >---------------------------

drvAsynIPServerPortConfigure("CYC", "localhost:9999",10,1,1)

dbLoadRecords( "/mnt/icfileserv/usr1/common/db/ccs2epics01.db", PORT="CYC" )

# asynSetTraceIOMask(FGC3,10,0x0005)

# asynSetTraceMask (FGC3,10,0x001f)

# var streamDebug 1

iocInit()

-------------------------< IOC start >---------------------------

asynSetTraceIOMask(CYC,0,0x0005)

asynSetTraceMask (CYC,0,0x001f)

# var streamDebug 1

iocInit()

Starting iocInit

############################################################################

## EPICS R3.14.12.2 $Date: Mon 2011-12-12 14:09:32 -0600$

## EPICS Base built Jan 18 2018

############################################################################

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

2018/01/23 15:17:06.452 CYC -1 registerInterruptUser

iocRun: All initialization complete

# exit

mmpsioc1>2018/01/23 15:17:31.110 drvAsynIPServerPort: new connection, socket=5 on localhost:9999

---------------------------------< IOC runtime DB >------------------------------------

record(ai,"CYC:START"){

field(DESC,"analog input record")

field(DTYP,"stream")

field(SCAN,"Passive")

field(INP,"@ccs2epics.proto WR_START $(PORT) 0")

}

record(ai,"ABC:01:DEVTYPE"){

field(DESC,"analog input record")

field(DTYP,"stream")

field(SCAN,"I/O Intr")

field(INP,"@ccs2epics.proto RD_ABC_01 $(PORT) 0")

}

record(ai,"ABC:23:DEVTYPE"){

field(DESC,"analog input record")

field(DTYP,"stream")

field(SCAN,"I/O Intr")

field(INP,"@ccs2epics.proto RD_ABC_23 $(PORT) 0")

}

(There are 18 more I/O Intr scanned records, which seems to match the reports from asyn registerInterruptUser)

---------------------------< protocol file >------------------------------------

One protocol per record. I added the 'out' commands as a diagnostic to see if I could make it respond.

WR_START {

out "START\n";

in "PLEASE %d";

}

RD_ABC_01 {

in "ABC,01,%d";

out "thanks\n";

}

RD_ABC_23 {

in "ABC,23,%d";

out "thanks\n";

}

RD_ABC_45 {

in "ABC,45,%d";

out "thanks\n";

}

Processing the Passive record 'CYC:START' by using dbtr in the IOC shell or by setting it to periodic scan causes streamDevice to emit:

2018/01/23 15:25:32.022206 _main_ CYC:START lockRequest: pasynManager->queueRequest: port CYC not connected

PV: CYC:START dbtr(dbProcess)

The connected telnet session doesn't complain, but characters typed don't seem to go anywhere that shows up in places I can inspect:

mmpsioc1>asynReport,3

CYC multiDevice:No canBlock:Yes autoConnect:No

enabled:Yes connected:No numberConnects 0

nDevices 0 nQueued 0 blocked:No

asynManagerLock:No synchronousLock:No

exceptionActive:No exceptionUsers 0 exceptionNotifys 0

traceMask:0x1f traceIOMask:0x5 traceInfoMask:0x1

interposeInterfaceList

asynOctet pinterface 0x760b40 drvPvt 0x247dc90

interfaceList

asynCommon pinterface 0x760b10 drvPvt 0x247a7b0

asynInt32 pinterface 0x767ce0 drvPvt 0x247a7b0

asynOctet pinterface 0x767c80 drvPvt 0x247a7b0

Port CYC: Connected

fd: 4

Max. clients: 10

Num. clients: 1

CYC:1 multiDevice:No canBlock:Yes autoConnect:No

enabled:Yes connected:Yes numberConnects 1

nDevices 0 nQueued 0 blocked:No

asynManagerLock:No synchronousLock:No

exceptionActive:No exceptionUsers 1 exceptionNotifys 0

traceMask:0x1f traceIOMask:0x5 traceInfoMask:0x1

interposeInterfaceList

asynOctet pinterface 0x760d00 drvPvt 0x7f9b00001790

interfaceList

asynCommon pinterface 0x757210 drvPvt 0x7f9b000008e0

asynOctet pinterface 0x7f9b000009c8 drvPvt 0x7f9b000008e0

Port localhost:9999: Connected

fd: 5

Characters written: 0

Characters read: 0

What is the meaning of the CYC:1 section in the above? Is there some kind of new pseudo port created by each client connection? Am I supposed to use that somehow? How? What is the meaning of 'autoConnect' in the context of a TCP server? It seems conceptually meaningless to me.

Is this even supposed to work? At the end of the day, I want to have data that is uniquely tagged and sent spontaneously on an irregular basis by the client to be associated with particular EPICS records, according to the tags, which I'm attempting to match in each streamDevice protocol. Any suggestions for alternative solutions are quite welcome.

Thanks.

Rod Nussbaumer

TRIUMF

Vancouver, Canada.

References:: asyn IP server port driver with streamDevice Rod Nussbaumer; RE: asyn IP server port driver with streamDevice Mark Rivers; Re: asyn IP server port driver with streamDevice Mark Rivers; RE: asyn IP server port driver with streamDevice Mark Rivers

Navigate by Date:: Prev: RE: asyn IP server port driver with streamDevice Mark Rivers; Next: RE: IOC build Mark Rivers; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024
Navigate by Thread:: Prev: RE: asyn IP server port driver with streamDevice Mark Rivers; Next: RE: asyn IP server port driver with streamDevice Mark Rivers; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024

ANJ, 25 Jan 2018

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System