Независимая от операционной системы коммуникация Межпрограммы между Python и C
Я имею очень смутное представление, что я делаю здесь, я никогда не делал ничего как это прежде, но друг и я пишем конкурирующие шахматные программы, и они должны смочь связаться друг с другом.
Он будет писать главным образом в C, мой объем будет в Python, и я вижу несколько опций:
- Поочередно пишите во временный файл или последовательные временные файлы. Поскольку коммуникация не будет всегда большой, это могло работать, но походит на ужасное обходное решение мне, программы должны будут продолжать проверять на файлы изменения / новые файлы, это просто кажется ужасным.
- Найдите некоторый способ управлять каналами т.е. mine.py |./его. Это походит на что-то вроде тупика.
- Используйте сокеты. Но я не знаю то, что я сделал бы, таким образом, кто-то мог дать мне подсказку к некоторому материалу чтения? Я не уверен, существуют ли независимые от операционной системы, независимые от языка методы. Должна была бы быть некоторая программа сервера супервизора для управления?
- Используйте некоторый протокол HTML, который походит на излишество. Я не возражаю против программ, имеющих необходимость работать на той же машине.
Что люди рекомендуют, и где я могу начать читать?
5 ответов
Если вы хотите и нуждаетесь в действительно независимом от ОС и языке межпроцессном взаимодействии, сокеты, вероятно, являются лучшим вариантом.
Это также позволит двум программам обмениваться данными между машинами (без изменения кода).
Для ознакомления с материалами, вот Практическое руководство по программированию сокетов Python .
Вы можете использовать Protobuf в качестве межпрограммного протокола и читать/писать из файла каждый по очереди.
Вы можете читать промежуточный файл каждые n секунд.
После того, как это заработает, вы можете перейти к использованию сокетов, где каждая программа будет запускать сервер и ждать соединения.
Изменение должно быть небольшим, потому что протокол уже будет protobuf. Таким образом, единственное, что вам придется изменить, это то, где вы либо читаете из сокета, либо из файла.
В любом случае вам понадобится протокол обмена.
edit
Упс, я неправильно прочитал и подумал, что это C++.
В любом случае, вот поддержка протобуфа на C, но это все еще работа над ним
Я бы сказал, просто напишите xml-файл, содержащий ходы для черного и белого.Отметьте в отдельном файле, кто сейчас очередь, и убедитесь, что только программа, чья очередь, будет записывать в этот файл, чтобы зафиксировать свою очередь.
Вот ссылка на предлагаемый формат xml для хранения ваших ходов, который придумала другая группа. http://www.xml.com/pub/a/2004/08/25/tourist.html
Две возможности:
Использовать IP-сокеты. В документации по Python есть несколько примеров. (Действительно не так сложно, если вы просто используете базовые функции чтения/записи.) С другой стороны, сокеты на C обычно не так просты в использовании.
Создайте третье приложение. Оно запускает оба приложения с помощью subprocess и взаимодействует с обоими приложениями через каналы. Шахматные приложения должны иметь возможность читать/писать только на stdin/stdout.
Это имеет дополнительное преимущество в том, что это приложение может проверить, является ли ход законным. Это помогает находить ошибки и поддерживать честные игры.
Сокеты с моделью клиент / сервер ...
По сути, вы и ваш друг создаете разные реализации клиента.
Локальный клиент показывает визуальное представление игры и сохраняет состояние фигур (положение, убит / не убит) и правила о том, что фигуры могут / не могут делать (какие ходы могут быть сделаны с какими фигур и проверено ли состояние доски).
Удаленный сервер хранит данные об игроках (чей это ход, заработанные очки, выиграна игра или нет), а также список сделанных ходов.
Когда вы делаете ход, ваш клиент проверяет ход в соответствии с правилами игры, а затем отправляет сообщение на сервер, в котором говорится: «Я сделал этот ход, ваша очередь».
Другой клиент видит, что поворот был сделан, берет последний ход с сервера, вычисляет, произошло ли движение, проверяет ход в соответствии с правилами игры и воспроизводит действие локально. После этого пользователь может сделать следующий ход (или нет, если игра окончена).
Самая важная часть взаимодействия между клиентом и сервером в играх - это отправлять как можно меньше данных и сохранять как можно меньше данных о состоянии на сервере. Таким образом, вы можете играть в нее локально или по всему миру с небольшой задержкой или без нее. Пока ваш клиент работает по тому же набору правил, что и клиент вашего оппонента, все должно работать.
Если вы хотите гарантировать, что никто не сможет обмануть, взломав свою версию клиента, вы можете сделать все расчеты положения и правил на сервере и просто сделать клиентов не чем иным, как простыми механизмами воспроизведения.
Причины, по которым сокеты являются лучшей средой связи, заключаются в следующем:
- ограничения межпроцессного взаимодействия почти так же сложны, как межузловое взаимодействие.
- Сеть широко поддерживается во всех системах.
- практически нет барьеров или нет - доступа к удаленному использованию, если вы выберете
- , сеть будет надежной, гибкой и проверенной
Это одна из причин, по которой многие крупные системы, такие как базы данных, используют сокеты как сетевое, а также локальное средство связи.