Связь между процессами

Question

Я ищу некоторые данные, которые помогут мне решить, что было бы лучше / быстрее для связи между двумя независимыми процессами в Linux:

• TCP
• Именованные трубы

Что хуже: системные издержки для каналов или служебные данные стека tcp?

---

Обновлены точные требования:

• нужен только локальный IPC
• в основном будет много коротких сообщений
• кроссплатформенность не требуется, только Linux

Answer 1

В прошлом я использовал сокеты локальных доменов для такого рода вещей. Моя библиотека определила, является ли другой процесс локальным для системы или удаленным, и использовала TCP / IP для удаленной связи и сокеты локального домена для локальной связи. Приятной особенностью этого метода является то, что локальные / удаленные соединения прозрачны для остальной части приложения.

Сокеты локального домена используют тот же механизм, что и каналы связи, и не требуют дополнительных затрат стека TCP / IP.

Answer 2

Я обсуждал это в ответ на предыдущий пост . Я должен был сравнить сокет, канал и общий доступ к памяти. Трубы были определенно быстрее, чем розетки (возможно, в 2 раза, если я правильно помню ... Я могу проверить эти цифры, когда вернусь к работе). Но эти измерения были только для чистого общения. Если коммуникация является очень малой частью общей работы, тогда разница между этими двумя типами коммуникации будет незначительной.

Редактировать Вот некоторые цифры из теста, который я провел несколько лет назад. Ваш пробег может отличаться (особенно, если я сделал глупые ошибки программирования). В этом конкретном тесте «клиент» и «сервер» на одной и той же машине отражали 100 байтов данных и обратно. Он сделал 10 000 запросов. В документе, который я написал, я не указал технические характеристики машины, поэтому только относительные скорости могут иметь любое значение. Но для любопытных время, приведенное здесь, является средней стоимостью запроса:

• TCP / IP: .067 ms
• Труба с портами завершения ввода / вывода: .042 ms
• Труба с перекрывающимся вводом / выводом: .033 ms
• Общая память с именованным семафором: .011 ms

Answer 3

Не думаю, что вам стоит беспокоиться о накладных расходах (которые будут смехотворно низкими). Используя инструменты профилирования, вы убедились, что узким местом вашего приложения могут быть издержки TCP?

В любом случае, как сказал Карл Смотрич, я бы пошел с сокетами, потому что в будущем будет очень тривиально разделять приложения.

Answer 4

Я не знаю, подходит ли вам это, но очень распространенным способом IPC (межпроцессное взаимодействие) в Linux является использование общей памяти. Это на самом деле очень быстро (я не профилировал это, но это просто общие данные в оперативной памяти с сильной обработкой).

Основная проблема вокруг этого приложения - семафор, вы должны построить вокруг него небольшую систему, поэтому вы должны убедиться, что процесс не пишет одновременно с попыткой чтения другого.

Очень простое учебное пособие для начинающих на здесь

Это не так переносимо, как использование сокетов, но концепция была бы такой же, поэтому, если вы переносите это в Windows, вам просто нужно изменить слой создания / подключения общей памяти.

Answer 5

Две вещи, которые следует учитывать:

1. Стоимость установки соединения
2. Стоимость непрерывной связи

В режиме TCP:

(1)более дорогостоящий - для (потенциально) ненадежного канала требуются трехсторонние рукопожатие.

(2) более дорогостоящие - служебные данные на уровне IP (контрольная сумма и т. д.), служебные данные TCP (порядковый номер, подтверждение, контрольная сумма и т. д.) почти всеиз которых нет необходимости на той же машине, потому что канал должен быть надежным и не создавать проблем, связанных с сетью (например, переупорядочение пакетов).

Но я бы все равно пошел с TCP , если это имеет смысл (т.е. зависит от ситуации) из-за его повсеместности (читай: легкая кроссплатформенная поддержка) и накладных расходов в большинстве случаев не должно быть проблемой (читай: профиль, не делай преждевременной оптимизации).

Обновлено : если кроссплатформенная поддержка не требуется, и акцент делается на производительность, тогда используйте named / domain pipe , так как я уверен, что платформаРазработчики форм будут оптимизировать ненужную функциональность, которая считается необходимой для обработки нарушений на уровне сети.

Answer 6

Использование TCP будет связано с дополнительными издержками - это будет включать разбиение данных на пакеты, вычисление контрольных сумм и обработку подтверждений, что не требуется при обмене данными между двумя процессами на одном компьютере. Использование канала просто скопирует данные в буфер и из него.

Answer 7

сокет домена unix - очень компромиссное решение. Не накладные расходы по tcp, но более эволюционные, чем решение для канала. Вы не учли, что сокет двунаправленный, а именованные каналы - однонаправленные

Answer 8

Я думаю, что трубы будут немного легче, но я просто догадываюсь.

Но так как каналы локальны, вероятно, здесь задействован гораздо менее сложный код.

Другие люди могут сказать вам попробовать и измерить оба, чтобы выяснить это. Трудно ошибиться с этим ответом, но вы можете не захотеть тратить время. Это оставило бы вас в надежде, что мои предположения верны;)