Programming Distributed Systems with YAMI4
1.2.1 Configuration Settings
The set of configuration options (in YAMI 3.x known as policies) has also changed. The following list describes all policies in YAMI 3.x and explains how the given concept is handled in YAMI4:
- agent level - In the early versions of YAMI there was an idea that not all programming languages can handle all supported data types naturally. The set of types was divided into two levels, where level 1 allowed only strings in parameter sets, whereas level 2 allowed all supported data types. Agents were created with carefully selected levels to ensure that only properly typed messages were sent between them. This concept was abandoned, and the data model in YAMI4 is the same for all supported programming languages.
- queue max lengths - In YAMI 3.x it was possible to limit the sizes of all queues and in particular incoming queues were accounted for separately for each object. In YAMI4 the queues are managed with incoming and outgoing water mark levels and the queues for incoming messages are merged into a single queue from which messages are dispatched to all objects.
- number of dispatcher threads - This concept was retained and is configured in the same way in YAMI4.
- number of sender threads - In YAMI4 exactly one I/O worker thread manages all I/O traffic and therefore this configuration option does not exist any longer.
- connection pool sizes - There is no limit (other than that imposed by the available memory and system resources) on the number of connections, so these configuration options do not exist any longer.
- number of send tries - In YAMI4 this option was retained.
- has listening socket - In YAMI4 this configuration option does not exist, as the listeners are created explicitly and there can be zero, one or many of them in a single agent.
- reuse address - This configuration option was retained for TCP protocol.
- has receiver thread - This option does not exist any longer, as there is always exactly one I/O worker thread that handles the traffic in both directions.
- has waker - In YAMI4 the alarm subsystem was abandoned and instead individual outgoing messages can be waited upon with independent timeouts and with much better resolution.
- multi-threaded user - This setting does not exist any longer, as it is assumed that all users are potentially multi-threaded.
- allow duplex connections - No longer necessary.
- receiver idle time - This setting is no longer necessary.
In addition to the above changes, the YAMI4 release introduced one new configuration option, TCP No-Delay, which default value switches off the Nagle algorithm for packet grouping and that setting differs from the previous YAMI version.