Как организовать обмен данными между приложениями?

Question

[Interface]

Доброго времени суток!

Сразу оговорюсь - в гугле не забанили, просто хотелось бы получить совет подкрепленный личным опытом

Возможно, банальная проблема, конечно, но все же...

Есть, положим, 2 программы (2 процесса). Как организовать между ними обмен данными в рамках одной машины (можно и не ограничиваться)?
Пишу без конкретики потому как хотелось бы получить максимально универсальное решение. Т. е. например, есть на Delphi написанная программа; есть, скажем, сервер на Node.js; есть какая нибудь еще софтина - каким образом можно организовать обмен данными между этим разнородным зоопарком?

Когда задавался этим вопросом в последний раз - остановился на сокетах. С одной стороны это в моем понимании:

• Легкий (в теории) переход от соединения 2 процессов в рамках 1 машины к соединению через сеть
  
• Кроссплатформенность
  
• Широкая поддержка этой технологии
  

Да и вообще сокеты вроде бы тут вполне подходят, однако меня беспокоит:

• Не окажутся ли сокеты бутылочным горлошком в плане быстродействия?
  
• Насколько это "костыльное" решение для межпроцессорного общения?
  
• Какие есть альтернативы?
  

Answer 1

[Дмитрий Ковальский]

Решение в лоб - создать общий ресурс для всех приложений. К примеру xml или маленькая база SqlLite. И пусть обе апликухи оттуда читают. Или вы хотите именно взаимные "пинки" заставляющие что-то делать?

Comments

[Interface]

Хотелось бы, что б это все было как можно быстрее. Не хочется обращаться к диску вовсе. Xml - это несколько другой уровень абстракции, мне нужно средство чем этот xml гонять туда-сюда. Пинки, если я вас правильно понял, тоже нужны. Т.е. один процесс должен "отловить событие" отправки другим процессом данных.

Answer 2

[sitev_ru]

Я за сокеты!

Comments

[xmoonlight]

Тогда поясни:
В чем разница: сокета и TCP-порта и именованного канала?)))

[Илья]

xmoonlight: сокет это интрефейс для обмена данными, а tcp вообще протокол, для контроля обмена. Они могут работать как вместе, так не вместе. Что за вопросы?

[Saboteur]

xmoonlight: tcp-port это номер порта в IP протоколе.
именованый канал - это файловая абстракция

Answer 3

[xmoonlight]

Нет... Решение в лоб - это IPC! )
https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D...

Comments

[Interface]

По вашей ссылке сокет является одним из методов IPC, получается сокеты - все таки лобовое решение? Хорошо ли это? :)

[xmoonlight]

Interface: то что Вы увидели в огромном списке знакомое слово - это хорошо, а вот что сделали такой вывод и посмеялись над собой - плохо.
Смотрите все методы и учите.

[Сергей Протько]

xmoonlight: в реальности методов не много:
- пайпы (unix only, на шиндовс боль и унижение)
- сокеты (работает всегда)
- шаред мемори (эффективно, но сложно и можно напороться на кучу грабель)

Все остальное - слишком специфично и подходит только в конкретных случаях. Так что имхо, если нужна кросплатформенность, то только сокеты.

[xmoonlight]

Сергей Протько: shared only или смысла даже браться стыковать нет... ИМХО.

[Сергей Протько]

xmoonlight: зависит от того насколько интенсивный обмен данными идет. По сути использование сокетов на лупбэк интерфейсе не сильно медленнее шаред мемори, сетевой стэк не задействуется.

Шаред мемори круто если у вас есть пачка данных, которые редко меняются и которые надо часто читать. Вот тогда это идеальный кейс для организации IPC. Если же данные меняются часто или вам надо обмен сообщениями организовать, то сокеты (особенно если сервер пишите не вы, а скажем, мы берем готовый zeromq) намного более рационально использовать.

[Сергей Протько]

xmoonlight: ну и да, шансы все запороть с шаред мемори намного выше чем с сокетами.

[xmoonlight]

Сергей Протько: ну если руки у кодера кривые - ничего не спасёт... ни сокеты, ни дублирование...

[Сергей Протько]

xmoonlight: да ладно вам, руки кривые, зачем специально повышать риски? Все банально упирается в юз кейсы которые мы хотим решить. Сокеты решают 98% задачь затрагивающих IPC эффективно как с точки зрения производительности, так и с точки зрения трудозатрат. Оставшиеся 2% - разработчики таких систем думаю не будут спрашивать на тостере что юзать для IPC.

[Сергей Протько]

xmoonlight: для контраста, я имел возможность баловаться со всеми перечисленными способами IPC, сейчас вот пилю медленно но верно менеджер процессов для symfony/process под свои нужды на пайпах. На пайпах Карл (не удержался, клиента зовут так).

[xmoonlight]

Сергей Протько: Карл на пайпах? - наверное это круто) (без пояснений - тут никак...)

[Сергей Протько]

xmoonlight: ну это мем такой...

[xmoonlight]

Сергей Протько: так... половина понятна, осталось понять какого клиента зовут Карл?)

[Сергей Протько]

xmoonlight: клиента по проекту, в рамках которого мне понадобилось написать менеджер процессов что бы распаралелить обработку одной простенькой штуки. Менеджер процессов давно уже просят в ишусах симфони, так что появилось желание законтрибьютить.....

Еще одна загубленная острота...

[xmoonlight]

Сергей Протько: "в рамках которого мне понадобилось написать менеджер процессов что бы распаралелить обработку одной простенькой штуки." - это обман)): либо штука не простенькая, либо можно обойтись без менеджера процессов) есть линк на шедевр?
"Еще одна загубленная острота" - к сожалению, я не владею телепатией, в плане понимания выражения) Возможно, это "тупость"/"необдуманный поступок"?! )

[Сергей Протько]

xmoonlight: пока нет, все не дойдут руки допилить вариант который можно показывать людям (в проекте сейчас используется написанный на скорую руку вариант), может на следующей неделе... На данный момент поделка эта умеет только генерировать процессы из итератора с возможностью отслеживания сколько одновременно процессов может быть запущено (в неблокируемом режиме, через proc_open). В планах сделать так же возможность не убивать воркеры и организовать общение с мастером через пайпы, что в принципе не сложно, но на это нужно время. Последнее мне нужно для того что бы сделать свой паралелизатор для бихата, ибо... при подходе с запуском воркеров на каждый чих, у меня половина времени выполнения одного воркера будет занимать его бутстрапинг.

Answer 4

[Максим Кузнецов]

1. Не создавать зоопарк. Ни при каких условиях.
2. Не пытаться найти универсальное решение для всего на свете. Такое решение всегда избыточно, неповоротливо, несопровождаемо, а, главное, никому не понятно. Исходите из конкретных требований и применяйте архитектурные паттерны.
3. Существует много общепринятых технологий обмена данными между компьютерами или между процессами на одном компьютере. Можно реализовать сетевое взаимодействие на низком уровне. Можно использовать уже готовые решения (SOAP, например). Можно использовать посредников (иногда это единственный способ избавиться от влияния зоопарка, созданного другими людьми). Причём посредники тоже бывают разные. Опять-таки, смотрите конкретные требования и паттерны.

Answer 5

[leventov]

Насчет "самого универсального" решения - почитайте вот это: tammersaleh.com/posts/the-number-one-trait-of-a-gr...

Зависит от типа взаимодействия. Если это обмен сообщениями, это одно. Берите сокеты или очереди. Если перекачка однотипных данных из процесса в процесс - та же очередь. Если это какое-то более сложное разделяемое состояние, например динамическое множество онлайн-пользователей с какими-то ассоциированными данными (если речь о серверах зашла) - возьмите уже полноценную in-memory базу данных.