IOHexperimenter should have a high-level binary implementing an "objective function as a service".
This would take the form of an executable that takes the problem configuration (suite, problem id, instance) as parameters and then watch I/O named pipes (cf. mkfifo in POSIX systems) as objective function calls.
For reference, I've implemented a generic proof of concept for Linux in nojhan/named-pipes-services. Thanks to the blocking nature of named pipes, the code is utterly simple and basically consists of a loop: reading an input file, calling the function, then writing to a file.
Such a service can then be very easily exposed on a network with the help of classical tools like socat.
jdreo
commented
2 years ago
IOHexperimenter should have a high-level binary implementing an "objective function as a service". This would take the form of an executable that takes the problem configuration (suite, problem id, instance) as parameters and then watch I/O named pipes (cf.
mkfifoin POSIX systems) as objective function calls.For reference, I've implemented a generic proof of concept for Linux in nojhan/named-pipes-services. Thanks to the blocking nature of named pipes, the code is utterly simple and basically consists of a loop: reading an input file, calling the function, then writing to a file. Such a service can then be very easily exposed on a network with the help of classical tools like
socat.Necessary steps: