As described, MsgConnect operates in connectionless mode. This means that to send a message, you just call one of SendMessage*() or PostMessage() functions and not think about establishing connection. MsgConnect should deliver the message for you and deal with connection itself when it is necessary for the transport. Connection management is necessary for InetTransport family of transports (SocketTransport and HTTPTransport now).
While automatic connection management works nice for regular data exchange, some advanced communications might require connections to be controlled, i.e. established and kept available all the time.
Let's consider the following scenario: the client sends a request to the server. The server immediately replies with confirmation code, however the actual reply will be sent later. Socket transport works in client-server mode, i.e. the server can't establish outgoing connection to the client. The following problem appears in this case: if the connection is broken or just dropped by the client, the server won't be able to deliver the reply to the client until the client reconnects. Obviously, such scenario requires connection to be established and kept available.
Following the concept of connectionless operations, MsgConnect doesn't offer direct control over connections in it's transports. Instead, it offers a very simple way to keep the connection alive. Just send an empty message to the recipient and the transport (in stmClient or stmP2P mode) will try to establish connection to this recipient.
The connection is dropped according to the setting of MCInetTransport.InactivityTime property. When the connection is not used for more than specified time (in milliseconds), it is dropped. If you want the connection to be kept forever, set the value of InactivityTime to 0. However there's a chance that connection is broken in the middle or when network interface fails or is restarted. In such case connection is re-established only when a message to be delivered exists. In our scenario there are no pending messages (and we expect the message to come from the server), so connection won't be re-established.
The solution is simple - sending a keep-alive message. The question appears - how to send a message in a way that will not cause significant network load and at the same time do the job of keeping the connection alive.
Keep-alive message should be sent only when there are no other (meaningful) messages to the same recipient. To do so, set MCMessage.Priority field to minimum value (-128). The message with such low priority will be sent only after all other messages going to the same recipient have been sent. Keep-alive message is sent on timer, i.e. once per certain time interval (once per second or per minute). The frequency really depends on the application needs. You must remember that the higher frequency is the more data is transferred (and network is loaded).
Should keep-alive message be sent using PostMessage() or SendMessageTimeoutCallback() method? On the one hand, message sent by PostMessage(), is a one-way message. The reply is not delivered to the originating system and network load is lower. On the other hand, your application might need to know if the keep-alive message was delivered or delivery failed with error. In this case SendMessageTimeoutCallback() is preferable way.
What should be the queue name, to which the message is addressed? In fact, this is not important. If you use PostMessage() to send keep-alive messages, you can specify any queue name (except empty). The message will be discarded on recipient site. If you use SendMessageTimeoutCallback(), however, using fake queue name will cause the message to be returned with "failed" status (and appropriate error code).
There exists one question to think about, when you implement keep-alive connections.
The question is how your clients are connected to network - do they use dial-up or leased line connections and whether they pay for time or for traffic. Keeping connection alive will force dialup connections to be established and kept active. With per-time payment for using phone line (for example cellular connection) such activity will cause losses for the user. Another thing is that each keep-alive message, although being tiny in size, can cause significant additional traffic. And there are networks (GPRS in cellular communications, certain xDSL lines), where users pay for the amount of data they send or receive. Using keep-alive messages in this case is also not desired.