Sensoray 2600 - Manual (Page 20)

Sensoray 2600 Programming Guide
16
Transactions
packet sizes, but also on how many other gateway transactions are already in progress. “Simultaneous” gateway transactions
are queued by the MM and executed in the order in which their command packets are received at the MM.
A msec value should be chosen that is at least as long as the worst-case transaction time after allowing for all of the above factors.
On the other hand, the value should be sufficiently short to ensure timely detection of a gateway transaction failure. The
programming examples in this manual use a somewhat arbitrary value of 1000 milliseconds. In most cases, this is far more than
enough time for a typical private LAN that imposes no routers between the client and the MM, yet it ensures that a transaction
time-out will be detected within one second.
In addition to communication latencies, transaction time-outs can also be caused by dropped packets or situations in which
multiple Ethernet clients are attempting to run too many simultaneous transactions.
5.7 Retries
A transaction retry is performed by re-sending a transaction’s command packet and waiting for its response packet to arrive, or a
response timeout, whichever comes first. If the MM did not previously receive the command packet, it will execute the commands,
and both cache and transmit the response packet. If the MM recognizes the command packet as being a duplicate of a previously
executed command packet, it will drop the packet (i.e., not execute the commands) and instead send the corresponding response
packet that was previously sent and cached. This retry mechanism relieves the client application of the responsibility for
communication error correction, and makes possible recovery from certain types of errors that would otherwise be unrecoverable
(e.g., reading data from a comport).
All gateway and comport transactions include a retries value that is specified in one of the middleware function calls associated
with the transaction.
When retries is set to a positive number, the middleware will automatically retry the transaction if it doesn’t receive a reply from
the MM within the transaction’s specified time-out interval. Transaction retries will repeat until a reply is received from the MM
or the specified number of retries have been attempted. If the maximum number of allowed retries have been attempted and there
is still no response from the MM, the transaction will fail with
GWERR_MMNORESPOND returned.
Retries are disabled when retries is set to zero. In this case, the transaction will fail with GWERR_MMNORESPOND upon the first
MM response time-out.
The worst-case transaction time equals the time-out interval times retries . This is the total elapsed time the application will wait
for a transaction to complete in the event of a MM communication failure.
A retries value should be chosen based on your network error rate, which in turn depends on whether collisions are possible
(e.g., your installation uses hubs instead of switches), cable lengths, electrical noise, and other factors. The programming examples
in this manual use a value of
1 , which is sufficient for most private LAN environments.