Introduction to Opt-Server Hosting

Remote solver execution made easy

The main purpose of the PIFOP Optimization Server feature — or just Opt-server — is to provide a convenient, flexible and secure way for universities and companies to give users (e.g. students, researchers, engineers) remote access to solvers that are installed on their premises.

Hosting an optimization server allows you to centralize the solver execution in one or few machines, giving your users the ability to solve their optimization models from anywhere, inside or outside your premises. All that they need is a browser with internet connection to access pifop.com.

The figure below illustrates the solver execution centralization via PIFOP Opt-server in an university campus.

image/svg+xml
Although the Opt-server hosting feature is primarily designed to meet the needs of universities and companies, you can also host an Opt-server for yourself, e.g. for running solvers that are installed locally in your machine.

Overview

The figure in the top of this page provides an overview of the system in which Opt-servers are integrated. Terminal commands entered by users of the PIFOP IDE are sent to the pifop.com central server, which in turn sends the commands to the selected Opt-servers. Opt-servers executes the commands and send the output back to pifop.com, which forwards this output to the IDE users.

Safely Isolated Program Execution

Each command line sent to Opt-Servers is executed within a sandbox of its own. The sandbox isolates the process running the command from the rest of the system, restricting what the proccess can do: what files it can read, where can it write to, how much memory it can consume, etc.

A Simple Example

Suppose that you have a project at PIFOP with the following three files: model.mod, data.dat and commands.run. Then you enter the following command line into a terminal while the Opt-Server My server is selected.

> ampl commands.run

What happens at My server when it receives that command?

First, it creates a directory containing all the files of your project as they appear to you at the PIFOP IDE, and a directory for writing temporary files. Then it creates a sandbox that can access some of the files and directories within the system. You as the optimization server manager has complete control over what directories can be read and written, but in general the sandboxed file system will include:

  1. The directory containing the files of your project.
  2. The directory containing the command executable — in this example, the ampl's directory.
  3. The directories containing the dynamic library dependencies of the executable.
  4. The directory created for temporary files.

The file system structure of the sandbox for our example would look something like this — directory names can vary:

/user-workspace/         (Project files)
/home/joe/ampl.linux64/  (Executable)
/lib64/                  (Dependencies)
/lib/x86_64-linux-gnu/   (Dependencies)
/tmp/                    (Temporary files)

With this file structure in place, the command line is executed from within the user-workspace directory.

As for the computing resources available for the process running the command, these can be limited by you as the Opt-server manager when configuring user groups.

Try it for free

When you subscribe to the Advanced plan, you get a 7-day trial period, which you can use, for instance, to test the Opt-server in your machine(s).

If you would like an Opt-server without having to setup and managing it yourself, we also offer Provisioned Opt-servers.
Terms and Privacy Help Pricing About Blog Contact us Server Status Twitter LinkedIn