Transport types for the remote object: process

Documents the process transport protocol supporting the remote object.

If the transport argument to CPXXopenCPLEXremote is processtransport, then CPLEX explicitly creates a new process which in turn instantiates the CPLEX Callable Library. CPLEX communicates with the newly created process using (named) pipes.

{"-stdio"|"-namedpipes=%s"}  [remote shell arguments] cplex "-worker=process" ["-logfile=%s"] ["-libpath=%s"]*

The process transport protocol understands the following arguments:

Other arguments are passed without change, exactly as they are, as command-line arguments to the new process that is started by the transport layer. These remaining arguments define the command line of the cplex process to be started. The following examples illustrate that point.

Example 1: Start a process on the local machine using named pipes in the current directory.

            char const *args[] = { "-namedpipes=.", "cplex", "-worker=process" };
            int status;
            CPXENVptr env;
            env = CPXXopenCPLEXremote("processtransport", sizeof(args) / sizeof(args[0]),
                                      args, &status);
          

Example 2: Start a process on the remote machine (remote.com for example) using named pipes of that process for communication.

          char const *args[] = { "-namedpipes=.",
                                 "/usr/bin/ssh", "remote.com", "cplex",
                                 "-worker=process" };
          int status;
          CPXENVptr env;
          env = CPXXopenCPLEXremote("processtransport", sizeof(args) / sizeof(args[0]),
                                    args, &status);
          

Both those examples assume that the cplex binary file is installed and accessible according to the environment variable $PATH. If such is not the case, then you need to specify a full path to the cplex binary file.

In Example 2, the cplex binary file must be installed on the remote machine (identified in the example as remote.com); and the binary file must be accessible in the remote $PATH environment variable there.

Example 2 also assumes that a remote login, not requiring a password, has already been set up and is available to the application.