Programs can exchange binary data buffers using data type TIBRVMSG_OPAQUE. The program is free to use any format and content within opaque data. However, extensive use of opaque data is not recommended.
For example, opaque buffers can contain data structures mapped by C language structs, but this technique couples the programs tightly to the data structure. If the
struct definition in the sender is changed, it must also be changed in the listener, and vice versa.
Exchanging structs makes it difficult to introduce new, interacting programs in the future. Furthermore, exchanging internal
structs makes it difficult for a program to interact with programs developed in other languages.
Binary data and internal structs are also platform dependent. Raw, binary data cannot be exchanged between programs running on machines that represent numbers or character strings with different formats.
Instead of binary buffers or structs, it is recommended to use TIBCO Rendezvous self-describing data to ease data exchange. Rendezvous data types span the most common atomic and array data types of most programming languages, and ActiveEnterprise wire format messages can emulate any struct or composite data type.
For example, a pointer is a memory address inside a particular computer. It has no meaning to any other program running on other computers. You must always send actual data by value rather than referencing it with a pointer.
Many opaque data structures or quantities are similarly meaningless outside of a particular program (for example, UNIX file descriptors). Do not send this kind of data to other programs.
Although transports do not prevent you from sending messages to wildcard subject names, doing so may lead to unexpected behavior in other programs that share the network. It is invalid for certified delivery transports to send to wildcard subjects.
For example, to exchange data up to 10,000 bytes, a single message is sufficient. But to send files that could be many megabytes in length, it would be better to use multiple send calls, perhaps one for each record, block or track.
TIBCO Rendezvous software can support high throughput, but all computers and networks have limits. Do not write programs that might flood the network with message traffic. Other computers must filter all multicast messages, at least at the hardware level and sometimes at software levels (operating system or TIBCO Rendezvous daemon).
Do not create loops that repeatedly send messages without pausing between iterations. Pausing between messages helps leave sufficient network resources for other programs on the network. For example, if a program reads data from a local disk between network operations, it is unlikely to affect any other machines on a reasonably scaled and loaded network; the disk I/O between messages is a large enough pause.
Publishing programs can achieve high throughput rates by sending short bursts of messages punctuated by brief intervals. For example, structure the program as a timer callback function that sends a burst of messages each time its timer expires; adjust the timer interval and the number of messages per burst for optimal performance.
When a program sends messages faster than the network can accommodate them, its outbound message queue grows. When any outbound message waits in the outbound message queue for more than 5 seconds, TIBCO Rendezvous software presents a
CLIENT.FASTPRODUCER warning advisory message. A program that receives this warning advisory message should slow its sending rate.
•
|
The service parameter specifies a UDP or PGM service (also known as a UDP or PGM port). The transport opens a UDP or PGM socket to that network service.
|
•
|
The daemon parameter specifies a TCP port number. The transport opens a TCP socket to that port.
|
These two types of socket are not interchangeable. Confusing the two leads to programming errors that are difficult to diagnose and fix. One source of this confusion is that the default TIBCO Rendezvous service (for TRPD daemons) is UDP service 7500, and the default daemon parameter is TCP socket 7500. Although these two numbers are the same, they specify different items.
Adapter configurations generated with the TIBCO Designer generic adapter palette creates predefined subject names based on global variables, which includes the adapter name, instance name, and schema class name.
If the predefined subject is not used, it is important to carefully plan the subject naming conventions for programs, and document them clearly for reference. Follow these guidelines:
•
|
Allocate the maximum storage for subject names. Subject name length is artificially limited to 255 bytes so that programs can allocate name buffers with a reasonable size. To maximize code reusability, allocate 255 bytes for buffers that are receiving subject names, even if the program does not use long names. In C and C++, the 255 byte limit is defined by the constant TIBRV_SUBJECT_MAX in the TIBCO Rendezvous header files.
|
Correspondent names have the same syntax as TIBCO Rendezvous subject names. For more information about the syntax of reusable names and practical advice on selecting a reusable name, see the
TIBCO Rendezvous Concepts.