From 6acf7c6294524f10a5e7b1f12a8397f910493547 Mon Sep 17 00:00:00 2001 From: Jeff Hill Date: Thu, 12 Aug 2004 18:40:32 +0000 Subject: [PATCH] o added additional data type doc o added more info on binding servers to interfaces --- src/ca/CAref.html | 71 ++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 61 insertions(+), 10 deletions(-) diff --git a/src/ca/CAref.html b/src/ca/CAref.html index 786efd679..bbf4f7068 100644 --- a/src/ca/CAref.html +++ b/src/ca/CAref.html @@ -772,14 +772,15 @@ specified in EPICS_CA_REPEATER_PORT.

Binding a Server to a Limited Set of Network Interfaces

The parameter EPICS_CAS_INTF_ADDR_LIST allows a ca server to bind itself -to, and therefore accept messages only from, a limited set of network -interfaces (each specified by it's IP address). Specifically, UDP search -messages addressed to both the IP addresses in EPICS_CAS_INTF_ADDR_LIST and -also to the broadcast addresses of the corresponding LAN interfaces will be -accepted by the server. By default, the CA server is accessible from all -network interfaces configured into its host. In R3.14 and previous -releases the CA server employed by iocCore does not implemet this -feature.

+to, and therefore accept messages only over, a limited set of the local +host's network interfaces (each specified by it's IP address). On UNIX +systems type "netstat -i" (type "ipconfig" on windows) to see a list of the +local host's network interfaces. Specifically, UDP search messages addressed +to both the IP addresses in EPICS_CAS_INTF_ADDR_LIST and also to the +broadcast addresses of the corresponding LAN interfaces will be accepted by +the server. By default, the CA server is accessible from all network +interfaces configured into its host. In R3.14 and previous releases the +CA server employed by iocCore does not implemet this feature.

Ignoring Process Variable Name Resolution Requests From Certain Hosts

@@ -1709,13 +1710,63 @@ properties such as units, limits, time stamp, or alarm status. The primitive C types follow a naming convention where the C typedef dbr_xxxx_t corresponds to the DBR_XXXX data type code. The compound (C structure) types follow a naming convention where the C structure tag dbr_xxxx corresponds to the -DBR_XXXX data type code. The following table provides more details on the +DBR_XXXX data type code. The following tables provides more details on the structure of the CA data type space. Since data addresses are passed to the CA client library as typeless "void *" pointers then care should be taken to ensure that you have passed the correct C data type corresponding to the DBR_XXXX type that you have specified. Architecture independent types are provided in db_access.h to assist programmers in writing portable code. For -example "dbr_short_t" should be used to send or receive type DBR_SHORT.

+example "dbr_short_t" should be used to send or receive type DBR_SHORT. Be +aware that type name DBR_INT has been deprecated in favor of the less +confusing type name DBR_SHORT. In practice, both the DBR_INT type code and +the DBR_SHORT type code refer to a 16 bit integer type, and are functionally +equivalent.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Channel Access Primitive Data Types
CA Type CodePrimitive C Data TypeData Size
DBR_CHARdbr_char_t8 bit character
DBR_SHORTdbr_short_t16 bit integer
DBR_ENUMdbr_enum_t16 bit unsigned integer
DBR_LONGdbr_long_t32 bit signed integer
DBR_FLOATdbr_float_t32 bit IEEE floating point
DBR_DOUBLEdbr_double_t64 bit IEEE floating point
DBR_STRINGdbr_string_t40 character string
Structure of the Channel Access Data Type Space