Geoff,
The Ethernet hardware layer and also most of the IP protocols include
CRC checksums that detect a limited degree of packet damage. This allows
degraded communication to continue over amazingly poor hardware links
because damaged TCP frames are retransmitted. However, if the number of
bits damaged in a packet is high enough then damaged IP frames can be
passed undetected up through the layers to CA. The UDP protocol also
includes a CRC checksum, but there is an option to turn this off with
certain IP kernels (not recommended).
The ECA_BADTYPE message you are receiving probably results from a sanity
check performed by the CA client library prior to swapping the bytes of
the incoming data. The incoming data type was probably damaged and
therefore out of range so CA passed the ECA_BADTYPE status code up to
the client side tool's call back function. There are many other protocol
sanity checks in CA so this situation would probably occur only in an
environment where the CA client library was discarding (sometimes
silently) many of the other messages from the server because of bad
resource identifiers and other problems. In contrast, the CA server will
disconnect from any client that sends a poorly formed request.
My guess is that you were able to connect because the CA client library
will repeatedly attempt to reconnect in an environment where many of the
frames are damaged and the server disconnects. In contrast, the read
request protocol is not reissued when it fails because CA assumes that
the TCP circuit, once established, is reliable. This is probably a
correct assumption because TCP circuits are reliable except in an
exceptionally poor network hardware environment.
I saw a situation where damaged packets appeared to be getting through
to CA on the LEDA project. I concluded at the time that this must have
been caused by some early 3com 10/100 switch hardware that was not
properly auto negotiating the link speed. After this experience, a new
procedure was initiated where IOCs were powered up after the switches if
the network infrastructure lost power, and this appears to have resolved
the problem.
The R3.13.1 patch release of R3.13 has changes to make the CA server
more robust in an exceptionally poor network hardware environment where
damaged frames are not detected by CRC checksums.
Jeff
> -----Original Message-----
> From: Geoff Savage [mailto:[email protected]]
> Sent: Wednesday, March 20, 2002 10:51 AM
> To: [email protected]
> Subject: ECA_BADTYPE
>
> Hi,
>
> We moved a computer in our control room yesterday and the CA clients
are
> returning a status of ECA_BADTYPE for some of the reads. The record
> being read is one unique to our hardware. The field is of type
> DBR_LONG. The switch reports errors on the port to which the host is
> connected. These errors are Align-Err and FCS-Err. Why would CA fail
> in this mode? I could see a problem with connecting but I don't
> understand a problem of performing a number of reads correctly and
then
> a number of reads fail with BADTYPE.
>
> Thanks for the assistance.
>
> Geoff
- References:
- ECA_BADTYPE Geoff Savage
- Navigate by Date:
- Prev:
Re: ECA_BADTYPE Steven Hartman
- Next:
RE: dbf_text vs. dbr_text Jeff Hill
- 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: ECA_BADTYPE Steven Hartman
- Next:
dbf_text vs. dbr_text Geoff Savage
- 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
|