Какой IPC здесь более эффективен?

У меня есть системное приложение, которое работает как коллекция из 12 процессов в unix. Существует процесс мониторинга, который обменивается данными с 11 другими процессами.

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

1) имеют связь со средой UDP, где эти 11 процессов будут периодически передавать данные в процесс мониторинга. процесс мониторинга просто прослушивает и фиксирует информацию, которая достаточно хороша.

ИЛИ

2) имеют реализацию общей памяти. поэтому имеется 11 разделяемых сегментов памяти, каждый из которых разделяется между двумя процессами (процесс ит и процесс мониторинга).

Для общей памяти это кажется быстрее, но требуется блокировка / синхронизация, где, как и в udp, kernel ​​копирует данные из памяти одного процесса в другой.

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

Координация разделяемой памяти сложна. Родитель должен знать, когда читать, какая часть каждого из 11 разделов разделяемой памяти, и дать ребенку знать, когда данные были прочитаны, так что часть разделяемой памяти может быть повторно использована и т. Д. Таким образом, хотя копирование может быть быстрее, остальная часть координации (возможно, с использованием наборов семафоров – возможно, с 22 семафорами, по одному для каждого направления из 11 каналов связи) означает, что вы почти наверняка найдете механизм, основанный на файловом дескрипторе, намного легче кодировать. Системные вызовы select() или poll() или варианта могут использоваться, чтобы сообщать вам, когда есть данные для считывателя. И kernel ​​имеет дело со всеми неприятными проблемами планирования и управления streamом и так далее.

Таким образом, используйте сокеты Unix-домена, если вы не можете действительно продемонстрировать, что вы получите преимущество в производительности из версии разделяемой памяти. Но ожидайте, что некоторые волосы (и некоторые данные) потеряют правильную реализацию общей памяти. (Вы можете продемонстрировать, есть ли преимущество в производительности для использования разделяемой памяти с сырой, ненаправленной системой синхронности, вы, вероятно, не пойдете в производство с сырой ненадлежащей синхронизированной системой.)

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

Кроме того, некоторые ядра поддерживают сеть с нулевой копией, и в этом случае отправка пакетов UDP из одного процесса в другой может фактически не требовать, чтобы kernel ​​копировало данные вообще, вместо этого оно просто перенаправляет основные страницы MMU в процесс назначения. Если это так, подход сокетов даст вам лучшее из обоих миров (эффективность и надежность).

В UDP доставка не гарантируется, и бывают случаи, когда пакеты отбрасываются даже в локальных соединениях. Таким образом, MMF, вероятно, будут лучше.