From http://dotnetjunkies.com/WebLog/kenbrubaker/archive/2004/02/14/7265.aspx, Ken Brubaker asks some more questions about reliable messaging in Indigo:
Not necessarily. When you create a Dialog Manager, which is the component that manages the Ack/Nack logic of reliable messaging, you inherit a default set of configuration setting for TTL, maximum buffered messages, timeouts, etc. In fact, below I've cut and pasted the defaults from the machine.config file, with a sample of how you might override these settings through config:
<dialogManager> <profiles> <clear /> <profile name="default"> <maximumBufferedMessages>1280</maximumBufferedMessages> <maximumMessageTimeToLive>01:02:00</maximumMessageTimeToLive> <minimumAssurances>Full</minimumAssurances> <peekTimeout>00:00:00</peekTimeout> <receiveTimeout>00:00:00</receiveTimeout> <sendTimeout>00:01:00</sendTimeout> <storeName>default</storeName> </profile> <!-- Sample profile: <profile name="At least once delivery dialog profile"> <lifetime>12:00:00</lifetime> <maximumBufferedMessages>1280</maximumBufferedMessages> <maximumMessageTimeToLive>02:00:00</maximumMessageTimeToLive> <minimumAssurances>AtLeastOnce</minimumAssurances> <peekTimeout>00:00:00</peekTimeout> <receiveTimeout>00:00:00</receiveTimeout> <sendTimeout>00:01:00</sendTimeout> <storeName>Memory dialog store</storeName> </profile> --> </profiles> <dialogStores> <clear /> <memoryDialogStore name="default" /> </dialogStores> </dialogManager>
You can also manually set these settings through properties on the DialogProfile object, which hangs off the DialogManager. See the SDK for more.
To me, this reliable messaging infrastructure really enhances the capability of the client. It makes the client truly a smart client -- one that isn't just firing messages into the ether with blind faith, but rather one that can participate as a first class distributed computing node. The client is thus elevated.
Certainly, reliable messaging comes with a cost and should be used only when the cost/benefit analysis is completed. Costs include increased message size, increased network traffic increased CPU utilization; the benefits are, well, reliable messaging. Another factor to consider when implementing is the kind of store to use: non-durable or durable. Non-durable equates to the memory store, meaning that if the application domain hosting the Indigo Service Environment goes away, all state information about the reliable messaing delivery assurances is lost. A durable store, on the other hand, preserves and hydrates the state of all message transmission, but comes at a higher cost. As you can see above, the default configuration is to use the Memory Store.
As we move forward, I expect there will be PAGs that help to do the cost/benefit analysis and architect the right reliable messaing solution.