See the <a href="config/cluster.html#SimpleTcpCluster_Attributes">configuration reference</a> for more discussion on the various <code>channelSendOptions</code> values. 

      	The various <code>channelSendOptions</code> values offer a tradeoff between throughput on the sending

      	node and the reliability of replication should the sending node fail. Here are some common options. In this discussion

      	"message" could be any message sent between the nodes, but in the context of this dicussion it applies to session changes

      	being replicated to other nodes.

      	<br/> 

      	<code>channelSendOptions="8"</code>

      	As far as the sender is concerned, the message is sent

				as soon as it has been placed in the queue on the sender for

				transmission to the other nodes. The message may not reach all of the 

				recipient nodes and may not be successfully processed on those nodes that it does reach. 

				This option offers the most throughput on the sender but the least reliability, as the 

				triggering request will complete without any knowledge of the success/failure of the session replication.

      	<br/>

      	<code>channelSendOptions="2"</code>

      	The sender will block the completion of the current request until all of the receiving nodes 

      	have acknowledged that they have received the message, but have not necessarily processed

      	that message. 

      	This option will result in less throughput on the sending node, because the message must be transmitted

      	and the acknowledgement received, but the reliability is greater than the asynchronous model. 

      	<br/>

      	<code>channelSendOptions="6"</code>

      	The sender will block the completion of the current request until

				all of the receiving nodes have acknowledged that they have received <u>and</u>

				processed the message.

				This option will have the least throughput (of these three) but the greatest reliability.

      </p>

      <p>