Bidirectional Communication Between Sessions

AIMMS PRO allows two sessions to communicate in a bidirectional, asynchronous way. This is accomplished by sending messages that serialize procedure calls made in one session, to a queue to which the other session is listening. When a listening session receives such a message it will deserialize the message, and execute the corresponding procedure call. The PRO library provides this basic functionality through the procedure

pro::DelegateToPeer(requestQueue, procedureName, flags)

One or Multiple Peers

You can use pro::DelegateToPeer in procedures for which you want to delegate the execution to another session in exactly the same manner as pro::DelegateToServer, where the requestQueue must be a queue to which you know the peer session is listening. If multiple sessions are listening to this queue, each of these sessions will execute the delegated procedure call.


In most cases you’ll want to send messages from a client session to a server-side session or vice versa. For these common cases, the PRO library offers two specializations, where you don’t have to specify the queue manually:


These specializations make use of the internal state of the PRO library to determine whether a procedure call is made at the client- or at the server-side session and act accordingly. However, if these specializations are called in a chain of server-side sessions, they may not behave as expected, because the PRO library is not able to determine unambiguously whether a particular server-side session acts as a client- or as a server-side session at any particular moment. In such cases, calling pro::DelegateToPeer with an explicit queue id that is also passed over to the other peer (for instance as an argument to the procedure in which pro::DelegateToPeer is called) will prevent such ambiguities.

Current Session Info

The following functions allow you to retrieve information about the latest started session by calling pro::DelegateToServer:

Message Flags

When delegating a procedure call through pro::DelegateToPeer, you can modify the way in which the message is being handled by AIMMS PRO by adding one or more message flags:

If you want to add multiple flags to a call to pro::DelegateToPeer, you should add all relevant flag values.

Waiting for Messages

You can explicitly wait for incoming procedure calls, through the procedure


This procedure will wait for a given timeOut time for messages that are sent to the specific queueID and with the indicated flags set. Any messages that satisfy the given criteria will be handled before the procedure returns, that is, delegated procedure calls encoded in the message will be executed. The procedure will return the number of handled messages, or 0 if no messages satisfying the given criteria arrived within the given timeOut. If you do not specify a queueID, the procedure will listen on all queues. If you do not specify flags, the procedure will handle all incoming messages.

Synchronous Workflows

By waiting for messages, you can create a synchronous workflow around the optimization requests that will be executed in server-side sessions. For instance, from within a server-side session you can send a message to the client session, and wait for a response for a given amount of time before continuing the execution. This allows you to steer the execution through feedback given by the end-user. By adding user flags to the message, you can make sure that you only wait for and handle those messages that are meaningful in the context of your application.

Return to AIMMS PRO Manual Index