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: Force TCP/IP reconnect from Asyn/Streamdevice |
From: | Christoph Schroeder <[email protected]> |
To: | Torsten Bögershausen <[email protected]>, <[email protected]> |
Date: | Tue, 23 May 2017 12:19:55 +0200 |
Hello, On 05/23/2017 11:40 AM, Torsten Bögershausen wrote:
On 23/05/17 10:53, Christoph Schroeder wrote:Hi Torsten, On 05/23/2017 10:40 AM, Torsten Bögershausen wrote:Which side does the retransmission ? The IOC ? The device ?The device retransmits a package that the IOC already received again and again until it gives up. The IOC sends duplicate ACK. It seems the acknowledge is ignored on the devices side.Now, well, it looks as if the reset was not processed by the IOC ? At least it didn't cause the TCP connection to be terminated, right ?Right, netstat tells me the connection is still established, but there is no flow of data anymore and the buffers are empty. The last package I reveived from the device is the TCP RST.Which OS are you using ? Which version of asyn ?My tests where done with Debian 7 and Debian 8. The asyn version is R4-30. The problem seems to be caused by a lower layer. I got the same problem with a simple TCP client I wrote and even with netcat, so Asyn isn't at fault here.You should be able to use the CONNECT_PER_TRANSACTION feature from asyn by using drvAsynIPPortConfigure("xx", "<host>:<port>[:localPort] http",0,0,0) (But I wonder if this helps, when your device seems to have such problems)
Thanks I will try this.
Another question: Is the IOC sending anything more to the device? And wait the response ? Why is it so quite on the line ? When the IOC polls the device, there should be some traffic coming out, I think. If there is nothing to be polled from the IOC, then it doesn't matter, if the underlying TCP connection is not working, half-broken or whatever.
The instrument sends unsolicited data starting directly after the connections is established. There is no active communication from the IOC to the device. Configuration of the device is separated and can be done via a webserver or a telnet port. Best regards, Christoph ________________________________ Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de