Using Caché Direct
Notes for Users of the Previous Versions
[Back] [Next]
   
Server:docs2
Instance:LATEST
User:UnknownUser
 
-
Search:    

Caché Direct is designed to be backward compatible, but in some cases there are behavior changes you should know about. Some of the architectural changes are worth highlighting for users of previous versions, who may want to adapt their applications to take advantage of the new features.

IPv6 Issues in Caché Direct
In the current release of Caché Direct, IPv6 address formats are fully supported. In particular, the Server/MServer property of VisM.ocx allows IPv6 addresses within the same general connection string format as previously.
However, depending on how they are used by an application, there may be some hazards that need to be confronted. Specifically, the connection string in Caché Direct is a colon-delimited expression of the following general form:
   CN_IPTCP:server_address[port]
where server_address is the master server and can be an IP address, a server DNS name, or the special name localhost.
On the return from setting the Server property (which is the mechanism to request a connection to the given server), the property is reset to reflect the result of the connection attempt. If the attempt was successful, a last piece was added containing the slave server address. In recent releases (since the introduction of the superserver), this piece was always the same as the second piece, making it redundant. If the connection attempt was unsuccessful, the value of the property was changed to the empty string, "".
Potential confusion arises with IPv6 addresses, which contain colons in the server_address part. IPv6 also supports more than one form of loopback address. Caché Direct supports all of these format variations. But, depending on the assumptions made by application code, the new addresses could cause incorrect behavior. The following describes how Caché Direct handles IPv6 addresses:
  1. The connection string is still in the same general format, given above. It recognizes the extent of the server_address by looking for the square brackets that enclose the port number.
  2. IPv6 has its own loopback form (::1) and also supports IPv4-style and “mapped IPv4” address forms. These look like ::a.b.c.d and ::FFFF.a.b.c.d, where a.b.c.d are the decimal bytes of the IPv4 address and FFFF is the two-byte sequence of all ones. So IPv4 loopbacks can be expressed as ::127.0.0.1 or ::FFFF.127.0.0.1 or ::FFFF:007F:0100 (low bytes come first in the address). All of these loopbacks are equivalent and don’t represent real addresses. In order to make meaningful comparisons, Caché Direct converts them all, whether from the registry or explicitly from application code, to the name localhost, which is recognized by the connection software and handled appropriately.
  3. Caché Direct no longer appends a third redundant piece to the connection string if the address is in IPv6 format (i.e., contains any colons). If a connection is successful, the Server property will contain the server to which a connection was made. For IPv6 format addresses, it will look like the simple form of the string it was given. For IPv4 or DNS names, or localhost, it will still contain the redundant third piece to maintain backward compatibility with versions of Caché prior to 5.1.
  4. If the application code relies on colons only representing piece delimiters in an IPv6 environment, it will likely fail.
The general approach is that, if a human can easily recognize what is meant by the connection string, then the software can, too. The parsing rules for the connection string are:
  1. The first part is the same as always, CN_IPTCP:.
  2. The next piece (the server, in IPv4 or IPv6 form, and port) is terminated by the closing square bracket after the port number. This eliminates any confusion caused by colons in the address.
  3. The inclusion of username and password in the connection string has been deprecated since the introduction of Cache security. However, both parameters are still recognized and handled correctly by Caché Direct in the extended IPv6 format.
Previous Shared Connection Behavior
The old VisM control was a single-threaded, shared connection mechanism. It had an MServer property, which was shared among all the VisM controls in the process. The property was actually a computed value that reflected the connection to the server. If any VisM changed it, it disconnected from any current server and made a new connection to a new server process. If it was set to an empty string, it disconnected from the server.
Communication occurred in a separate thread.
New Architecture
The new VisM control has a new internal structure with three layers: the VisM objects, the CDConnects to which they are connected, and below that, the server processes that are attached to the CDConnects. The CDConnect has several qualities that are particularly relevant to this discussion:
Because there are now three layers and because of how the CDConnect layer is designed, there is a great deal more flexibility of Caché Direct applications. You can create client/server relationships that were not previously possible. Also because there are simultaneous separate connections, you can have a multithreaded application. Each connection still has a separate communication thread that it manages. Note that each connection must still be synchronous, because the server job itself is single-threaded and can only handle one message at a time.
Behavior Notes
Given the changes described here, a backward compatibility problem arises for some situations. The new VisM tries to behave the same way for the most common cases. Where it can not, it tries to do the most expected thing.
This version of VisM provides a property called Server, which you use to connect to Caché. For backward compatibility, VisM still has a property with the older name, MServer. In most situations, these properties are interchangeable. These properties do behave differently in the case where the VisM control has not yet been connected to a server.
If the application sets either the Server property or the MServer property, the behavior is as follows:
Also, this version of VisM provides new methods, which you can read about in the chapter Basics of Using the VisM Control. These methods are Connect(), SetServer(), and DeleteConnection().
As of Caché version 2007.1, you can use a connection tag as the first argument to SetServer(). You can also now set the Server property (or the MServer property) equal to a connection tag.
Other Architecture Changes