> We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?
Which SLAC systems are still running 4-18? That is a very old release, and there have been a number of fixes since then, some of which were particularly targeted at SLAC/LCLS.
These are the major fixes from the release notes that affect drvAsynIPPort and timestamps (which were done for SLAC/LCLS).
I am rather doubtful that a cherry-pick is going to work since there have been so many changes since R4-18.
Added the option to automatically close the port when there is a read timeout. This was done by changing the syntax of the drvAsynIPConfigure command from
userFlags: bit-wise ORed:
- Bit 0 is USERFLAG_NO_PROCESS_EOS. If 0 then asynInterposeEosConfig is called specifying both processEosIn and processEosOut.
- Bit 1 is USERFLAG_CLOSE_ON_READ_TIMEOUT. If 1 then the (TCP) socket will be closed when read() returns a timeout.
- Bit 2--31 are reserved, set to zero.
This change is backwards compatible since bit 0 is the same as the previous noProcessEos. Thanks to Torsten Bogershausen for this change.
Fixed a bug in calling poll(). Previously the status return from poll() was not being checked; it was assumed that when poll() returned the port either had new data or had timed out. This is not correct, because
poll() can return prematurely with errno=EINTR if a Posix signal occurs before data is received or the timeout expires. This can happen, for example, when the Posix high-resolution timer routines (timer_create, etc.) are used in the IOC. The Prosilica vendor
library uses the Posix timer routines, and there were problems using asyn IP ports in IOCs that were also running Prosilica cameras. The problem was fixed by calling poll() again if it returns EINTR and the desired timeout time has not expired since poll()
was first called.
Added support for AF_UNIX sockets on systems that provide them.
Added support functions for setting timestamps in asyn port drivers. These can be used to set the timestamp when the port driver received data. The driver can then set the asynUser->timeStamp field to this value
for all input records on read and callback operations. Records that have TSE=-2 will have this timestamp. There is support for registering a user-supplied function to provide the timestamp, which will override the default source that just calls epicsTimeGetCurrent().
Restored the original versions of pasynManager->lockPort and unlockPort that were used in asyn prior to R4-14. These versions just call epicsMutexLock and epicsMutexUnlock. In R4-14 these versions were replaced
with versions that queued requests to lock the port. The R4-14 versions fixed a problem with the interfaces/asynXXXSyncIO functions, but it has become clear that the original versions are useful in some circumstances. The change was done as follows:
- The lockPort and unlockPort functions in R4-20 were renamed to pasynManager->queueLockPort and queueUnlockPort.
- The interfaces/asynXXXSyncIO functions were all changed to call the queueLockPort and queueUnlockPort, so they function identically to how they have since R4-14.
- The versions of lockPort and unlockPort that existed prior to R4-14 were restored to pasynManager.
Changed the report() function so that if details<0 then asynManager does not print information for each device (address). It calls pasynCommon->report(-details) in this case so driver report functions will not
Changed the asynTrace print, printIO, vprint, vprintIO functions so they use EPICS_PRINTF_STYLE. This causes the GCC (version 3.0 and higher) and clang compilers to check the agreement of format strings with function
arguments when using asynPrint() and asynPrintIO(), just as they do with printf(). This is very helpful in finding errors, and uncovered a number in asyn itself, which have been fixed.
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Paduan Donadio, Marcio
Sent: Friday, June 02, 2017 5:54 PM
Subject: Re: asyn timeout
Probably it will work very well in our case. I will try this here and return to you as soon as I have a result. Thank you for this!
We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?
Thank you again,
Software Engineer - SLAC - TID/AIR/ACS
Have you looked at the asyn R4-29 release notes? It says this:
drvAsynIPPort now also directly supports the asynOption interface for 2 key/value pairs.
- key="disconnectOnReadTimeout", value="Y" or "N". This option replaces the USERFLAG_CLOSE_ON_READ_TIMEOUT that was introduced in R4-27.
The advantage of using the asynOption interface is that this behavior can now be changed at run-time, rather than being set once when the driver is created.
Since your device sends data every second, you can set the "disconnectOnReadTimeout" option and then read the device with a 10 second timeout. If it times out then it will reset the connection. Would this work
I am sorry to resurrect such an old thread. Mark, did you implement the optional keepalive support to the asyn socket driver, yet?
Here in SLAC we are seeing a scenario where it would be really useful. We have an equipment that sends data each second through a serial to ethernet converter. This equipment
does not accept any commands. Eventually, the converter reboots and Asyn receive no warning. So, for Asyn, we have an alive connection with no data, and for the converter, there is no active connection.
I tried this using only telnet without an IOC running and the behavior is the same: telnet does not know that the connection was broken with the converter.
The keepalive parameter would help us a lot in this case.
Software Engineer - SLAC - TID/AIR/ACS
Re: asyn timeout
Mon, 19 Oct 2015 18:24:12 -0300
I'd be happy to test the keepalive option when it's ready. It may not happen immediately since the instrument is a shared resource and the time to use it is allocated in blocks.
It seems like it might be a good idea to add optional keepalive support to the asyn socket driver. If I were to create a branch on github that implemented this would you be
able to test it?