Создание и работа с API программы
 

Здравствуйте!
Вводная:
Есть программа по расчету некоторой величины в логической игре.
Возникло предложение, разнести графический интерфейс пользователя от вычислителя в разные программы. Человек отдельно, Компьютер отдельно.
Для этого необходимо каким-либо образом наладить взаимодействие этих программ друг с другом.
Единственный имеющийся у меня опыт подобных взаимодействий - через сетевой сокет, и то, я не до конца понимаю, как это получается.
Т.е. в теории отправили, получили, но на практике в студенчестве синхронности(динамическая игра) мне достичь не удалось. Т.к. игра пошаговая низкие задержки сети мне не слишком страшны, но все же.
Сейчас "Решатель" выполнен отдельным потоком и работает постоянно анализируя ситуацию. Пока ситуация терпима, но как только заставляем его думать "вглубь" на несколько шагов, ситуация меняется до катастрофической.
Для взаимодействия программ AFAIK необходим некоторый API-Программный интерфейс программы, в который можно будет записывать поле игры, управляющий интерфейс для получения сиюминутного ответа, запуска, остановки и т.д. и интерфейс ответа. Соотв в GUI также должны быть предусмотрены интерфейс взаимодействия программ.

Вопрошательная :)
У консольный программ есть 3 стандартных потока. Поток ввода, поток вывода и поток ошибок. Если реализацию "Решателя" сделать консольной, т.к. графика там не нужна в принципе, то каким образом из другого графического приложения можно взаимодействовать с его стандартными потоками?
Есть Inter-process_communication (IPC), но найденный пример использует дополнительную библиотеку, что мне не совсем нравится.
Какую технологию взаимодействия программ можно применить, чтобы она была достаточно гибкой, для дальнейшей реализации клинет-сервера. Протокол взаимодействия сейчас создается, и к серверу хотелось бы создать API, чтобы "отвязаться" от платформы.
Интересует грамотная документация и внятное объяснение технологий взаимодействия. Может литература какая в свободном доступе есть? Т.к. мои рассуждения про API и IPC достаточно условны, вроде как знаю о чем говорю, а вроде как и нет.

Эти части будут работать на одной машине или на разных?

BlackEric, пока на одной.
Пока читаю про технологию CORBA и пытаюсь в Lazarus в Linux создать соединение SimpleIPCServer и SimpleIPCClient.

Сейчас это выполняется в рамках института, соотв. ПО учебно тренировочное, однако потом в планах работа с другой программой с расчетом на супервычислителях, поэтому практика программирования многопоточности и межпроцессного взаимодействия не помешает.

Тогда посмотрите в сторону Memory Mapped Files.

А почему бы вам не сделать обмен данными через БД?
Из одного процесса складывать, другим - забирать?

А не слишком ли это большая конструкция? Ради обмена данными БД поднимать? Отдельный процесс, дополнительное обращение через посредников к таблицам БД, соотв. проблемы переносимости и т.д.
В дальнейшем может быть да, можно будет в БД складывать техническую информацию для анализа производительности алгоритма, но сейчас наверно рано поднимать такие конструкции.

Почему бы вам просто не использовать COM?

Нечто работает на одной и той же машине... А зачем, простите за дурацкий вопрос, все это делить на принципиально разные части? Ну, изначально: GUI хотелось отдельно, решатель - отдельно. А потом дошли, что и GUI не важно, и консоль пойдет... Дык зачем все эти Кобры (ну, Корбы) разные с гадюками напополам, и прочие прибамбасы? Зачем делить, вот в принципе?

Задача сейчас решается с помощью сокетов. В Delphi есть нормальные компоненты, у них же есть вменяемые примеры работы с ними - банальной пересылки n`ого кол-ва байт.
В родных примерах COM/CORBA еще не искал, пока цейтнот по времени.
Тут смотря какую цель преследовать. Если цель - создать решатель, тогда разделением можно не заниматься.
Полезной нагрузки, согласен, программа не несет. Рассматривается она - как учебное пособие, т.е. студентке была предложена проблема поиска слов, и в нагрузку - принципиальное разделение интерфейса (GUI или TUI, не важно) от решателя.
Лично мной преследовалась цель отработки взаимодействия приложений друг с другом. Кроме сокетов, я ни с чем не работал, поэтому мне это тоже интересно.
Интересно создать пусть примитивное, но распределенное ПО с технологией клиент - сервер.
Опять же для того, чтобы не рассуждать про абстрактные вещи, а иметь некий малый опыт работы с ними "вживую".
Отсюда и идет это принципиальное разделение - пусть осваивают технологии и абстракции, пока есть время в ВУЗе, тренируясь на тряпичных кеглях.
Мне интересно, студентке тоже интересно. И это хорошо.
----
Кстати хочу похвалиться (чуть чуть совсем :) ), она освоила работу с потоками (создание/запуск/остановка, до семафоров пока не дошли), и у нее от новых возможностей буквально "горят глаза(!)", ну разве это не здорово?