Below is a list of the available data transfer modes
TINE allows both synchronous and asynchronous data exchange. Synchronous data exchange is easier to understand and easier to program, but is generally much less efficient than asynchronous data exchange. With synchronous data exchange, a client would simply make a call to ExecLink(). When the call completes, the data-exchange activity is over: The data have either been acquired or an error code has been set.
However, unless it is making use of the multi-threaded library build, the process calling ExecLink() is completely blocked until the call completes. This is a very annoying side-effect if a client is talking to several servers, and one of them is down. From the server side, the request for data-exchange is treated as an isolated case. That is, no persistent record of the client or the contract is kept, and if several clients in fact want the same thing, a server must deal with each one individually. This can be an annoying burden on the server if the number of synchronous clients wanting the same thing is large. On the other hand, a client could set up an asynchronous data-exchange link via a call to AttachLink(). When programming asynchronously, one inevitably deals with callbacks. Although it is possible to avoid them in TINE, it is strongly suggested that you use them. In other words a call to AttachLink() is guaranteed to complete immediately (unless the CM_WAIT access bit is specified). When the requested data transfer completes, the data set registered in the call to AttachLink() will be updated and a user-defined callback function will be called (see the discussion concerning AttachLink()). In principle, one could ignore the callback and simply assume that the data set always represents the current server data. However this is dangerous, as the callback function will also be called upon any error condition (including timeout), giving a client the chance to take appropriate action. You should also consult the section on Data Flow Tips to get a better idea of how to set up communication links between clients and servers.
Following in the asynchronous vein, TINE permits "Network Links" as well, where a call to AttachLink() can request that the data be sent to the entire network and not just the caller. To the developer, the callback logic is identical to normal asynchronous links. To specify a "Network Link", the transfer mode only needs to turn on the CM_NETWORK bit. In most cases, client programs do not run often enough concurrently to warrant this action. Occasionally though, there are a sufficient number of clients requesting a large amount of data (for instance video), so that this does turn out to make sense. If a client program demands 10 Kbytes from a server, and the client program is so popular that it is run on 10 stations, then the server must deliver the same 10 Kbytes to 10 different customers. One can reduce the demand for bandwidth and at the same time relieve the server of a bit of work by writing the client program so that it requests a broadcast to the network instead. Then, the server sends the 10 Kbytes only once, and all 10 customers get it nonetheless.
The CM_NETWORK switch will signal the server to dispatch the data via multicast. On some legacy operating systems (MSDOS, VMS) there is no multicast option available. In these cases the server will in addition dispatch data via broadcast if the optional configuration file ipbcast.csv was found during initialization. An example file is shown below:
TINE uses connectionless communication by default (i.e. datagrams). This is in the vast majority of communication scenarios sufficient, especially regarding console applications where displaying the most recent data is of primary importance (idempotent) and the "best-
effort" strategies of UDP datagrams (or IPX datagrams) are fine. Under some circumstances, where a higher "quality of service" is required, it could be desired to run data communication over connected sockets (TCP vs UDP, for instance). This might be the case, for example, for middle layer servers or possibly where transactions should not be 'repeated' if at all possible. This can be achieved in TINE by applying the CM_CONNECT bit to the requested access mode. In such a case, the peer-to-peer communication (from this client to that server) will go via a connected socket. Note, however, that at the server side, each connected client takes up extra resources, and a front can specify how many connected clients it will allow, via the tcpConTblSize variable (default in most cases is 32). It is usually only under special circumstances that a client should request a connection. In almost all cases, the connectionless communication has been made reliable enough, to the extent that "commands" sent from the client require an acknowledgment and are retried following timeout.
A potential problem arises when the initial command arrived at the server and was executed, whereas the acknowledgement was lost in transmission. As long as 'gRetardSingleContractRemoval' is set to TRUE (the default) such retries are flagged with CM_RETRY and a server accepting the retry will re-transmit the results of the first call. If CM_RETRY is FALSE, the server cannot re-transmit the results of the previous call since it has disgarded them. In such cases, the command could be issued twice. In TCP, retransmission of missing packets occurs at the network layer.
TCP connections are also necessary for JAVA applets, which are not allowed to open a UDP socket unless the local policies allow it.
Another possibility for increasing quality of service and utilizing the full benefits of the flow-control mechanisms of the underlying network stack is to make use of the CM_STREAM switch when setting up a data link. As in the case of CM_CONNECT, this signals the TINE transport engine to transfer the data via a connected socket. However there are noteable differences between the two. With CM_CONNECT, the data transfer does indeed occur via connected socket (tcp/ip). However, the requested 'timeout' parameters for the data link are absolutely respected. As a rule, tcp/ip interally waits a very long time (minutes) before giving up on an endpoint. Thus, it can do a very good job of "guaranteeing" delivery, but the amount of time required to deliver is not known to any appropriate degree of accuracy. Thus a connection using CM_CONNECT might work fine under normal network conditions and timeouts but the same connection over a 'slow modem' which might otherwise work fine will more than likely end up 'timing out'.
For data communication that needs to reap all delivery benefits of connected sockets (while forgoing any control over the time of delivery) one can use the CM_STREAM switch. The data communication will then take place on separate threads (both client and server MUST be using the multi-threaded TINE libraries) and will NOT impose any timeout contraints on the delivery. Indeed, the only timeout contraint is imposed on establishing the initial peer-to-peer connection.
Steam connections using CM_STREAM have been tested up to transfers of .5 Gigabytes. Note however that such large transfers require at least twice the payload size to come from main memory!
Many API calls to access take an access 'mode' parameter. This specifies the nature of the requested communication paradigm. For example, AttachLink() can request a single asynchronous transaction by setting the 'mode' to CM_SINGLE. The call to AttachLink() completes immediately and the given callback is fired when the the transaction has completed. Similarly a monitor can be established by supplying a 'mode' of CM_DATACHANGE (send on change of data only), CM_TIMER (send on requested polling interval) or CM_EVENT (send when scheduled at the server).
The 'mode' parameter consists of a 'base' mode and an optional modifier. The 'base' mode must be one of a mutually exclusive set. Whereas a mode modifier is used to pass further communication specifications. Note that occasionaly some modifiers might be also be mutually exclusive. For example specifying the CM_NETWORK flag (send as multicast) and the CM_CONNECT flag (send via a connected TCP socket) cannot work together. In such conflicts, only one modifier will be applied (here the CM_CONNECT will be excluded).
1.5.8