5 Overview

In this section we present the basic mechanism of the OptServer.

• Sec. 5.1 (Synchronous Optimization)

• Sec. 5.2 (Asynchronous Optimization)

• Sec. 5.3 (With or without the MOSEK API)

• Sec. 5.4 (Open or encrypted mode)

5.1 Synchronous Optimization

The easiest way to submit an optimization problem to the OptServer is in synchronous mode, where the caller is blocked while waiting for the optimization:

1. A submission request is sent over to the OptServer and the problem is transferred.

2. The submitter is put on hold.

3. The OptServer runs the optimizer and wait for the results.

4. When the optimizer terminates the OptServer collects the result and passes over to the client.

5. The client receives the solution and resumes.

The process can be represented as in Fig. 5.1.

This workflow has the following advantages:

• It is effective for problems where the solution is expected reasonably quickly.

• The changes to the code compared to a local optimization are almost nonexistent. They boil down to invoking a different method in place of the usual optimize or similar.

5.2 Asynchronous Optimization

The OptServer accepts jobs also in asynchronous mode, where the client is not blocked while waiting for the result:

1. A submission request is sent over to the OptServer and the problem is transferred.

2. The client regains control and continues its own execution flow.

3. The client can poll the OptServer at any time about the job status and solution availability.

4. The OptServer runs the optimizer and wait for the results.

5. When the optimizer terminates the OptServer collects the results, which are available to the client next time it queries.

The process can be represented as in Fig. 5.2.

Asynchronous mode is particularly suitable when

• A job is expected to run for long time.

• One wants to submit a set of jobs to run in parallel.

• The submitter is a short-lived process.

5.3 With or without the MOSEK API

Calling OptServer using the MOSEK API

The MOSEK API provides an interface to invoke the OptServer from the client, both in synchronous an asynchronous mode. It is currently available for the Optimizer API (synchronous and asynchronous) and Fusion (synchronous). The API is a set of functions such as optimizermt, asyncoptimize, asyncpoll and similar, which form a replacement for the standard optimize call, while the rest of the MOSEK code (creating task, loading data, retrieving results) remains the same. The details and examples can be found in the manuals for the Optimizer and Fusion APIs. It is possible to retrieve the log via a log handler and to interrupt a solver from a callback handler also during remote optimization.

Calling OptServer directly

Alternatively it is possible to call the OptServer through a REST API, submitting an optimization problem in one of formats supported by MOSEK. In this case the caller is responsible for assembling the data, communicating with the solver and interpreting the answer. Details and examples can be found in Sec. 7 (REST API tutorials). Using this approach it is possible to perform optimization from environments that cannot support a MOSEK client, for example from a Web application.

5.4 Open or encrypted mode

The server can be used in two modes.

Fully open

If no SSL keys are provided at installation, the server will run using HTTP only, without any user authentication, with anonymous job submission open to everybody and without the possibility to use the Web GUI. This is the only mode supported by the MOSEK client API up to version 9.1.

Encrypted

If SSL keys are provided at installation, the server will run using HTTPS only (also for job submission). Users need to be authenticated (for example via tokens) unless anonymous submission is explicitly enabled. In this mode it is possible to enable the Web GUI. See Sec. 6.3 (Security).