Совместное использование состояния между процессами в разных сетевых пространствах имен

Обновление вопроса с дополнительной информацией:

У меня есть 32 сетевых пространства имен в Linux Ubuntu 14.04, и в каждом пространстве имен запускается программа C. Я хочу, чтобы программа могла делиться некоторыми данными со своими братьями и сестрами в других пространствах имен (не потоки, отдельные процессы). Как это может быть сделано? Я не могу выполнять многоадресную рассылку UDP, поскольку каждое пространство имен имеет свой собственный сетевой стек, а пакеты, отправленные в многоадресный домен, не видны другим пространствам имен. Я также не могу думать о том, чтобы сделать это чисто через память mmap.

С помощью mmap() каждый процесс может одновременно пытаться выполнить запись на карту. Кроме того, когда один процесс выполняет запись, другие должны иметь возможность понять это и обновить свою структуру данных с помощью этого нового содержимого. Им разрешено писать, как только каждый процесс узнает об этом предыдущем обновлении. Вот почему я сначала подумал об использовании сокета UDP Multicast для связи, он очень хорошо работает для 32 процессов, но они должны находиться в одном и том же пространстве имен.

Кроме того, насколько я понимаю, сокет домена Unix не позволяет работать нескольким устройствам чтения/записи.

Ценим любую помощь!


c networking ipc process linux-namespaces
person user2511788    schedule 13.03.2016    source источник
comment
Вы должны иметь возможность совместно использовать память процессов, используя mmap. Почему вы думаете, что это не сработает? И если вы хотите сделать это с передачей сообщений, как насчет использования доменных сокетов UNIX?   -  person Andy Schweig    schedule 13.03.2016
comment
Спасибо за комментарии! 1. Каждый процесс хочет отправить некоторые данные каждому другому процессу, и эти процессы должны знать, что данные были отправлены ему, и обновлять свой внутренний кэш этими данными, которые были отправлены процессом №1. Точно так же каждый другой процесс может захотеть обновить отображаемую память своими данными, чтобы каждый другой процесс получил уведомление и мог обновить свои собственные данные. Сокет домена UDP - может ли он работать с несколькими писателями / несколькими читателями? Насколько я понял, только 1 писатель и 1 ридер (bind/connect). Еще раз спасибо, пожалуйста, дайте мне знать, если я что-то пропустил.   -  person user2511788    schedule 13.03.2016
comment
Также сокеты домена UDP работают только в режиме 1 писатель/1 читатель? Если 32 процесса захотят записать в другие процессы, которые получат эти данные, возможно ли это? Я мог бы сделать это с многоадресным сокетом, но он не работает в сетевом пространстве имен, поскольку каждое пространство имен имеет свой собственный домен многоадресной рассылки. благодарю вас.   -  person user2511788    schedule 13.03.2016
comment
Настоящая причина того, что mmap у меня не работает, заключается в том, что процесс № 1 может обновлять его, но процесс № 2-32 также может пытаться писать. Как только эта гонка решена, процесс № 1 пишет и хочет, чтобы другие обновили свои данные этим содержимым, тогда следующему процессу разрешается обновлять его. Я могу оставить в отображении несколько 100 миллионов байт, но как двигаться вперед и продолжать добавлять новые записи, убедившись, что старые записи читаются и обновляются каждым процессом? Каждая запись занимает около 100 байт, и записи добавляются очень быстро, порядка миллисекунд.   -  person user2511788    schedule 13.03.2016
comment
Может ли какой-либо процесс пропустить то или иное обновление, сделанное любым другим процессом?   -  person alk    schedule 13.03.2016
comment
Также нужно ли этому блоку делать что-то еще, кроме копирования данных? Прикинем: 32 процесса * отправка 31 процессу * 100 байт * 8 бит * каждую 1 мс. = apx 800mb/s Это довольно много, по крайней мере для ванильного железа. И если никакие данные не могут быть потеряны, вам также необходимо добавить служебные данные протокола.   -  person alk    schedule 13.03.2016
comment
В любом случае, предполагая, что ни один процесс не может пропустить какое-либо обновление: для снижения усилий по реализации настройте другой процесс, выполняющий базу данных в памяти, обслуживающую все 32 процесса.   -  person alk    schedule 13.03.2016
comment
Нет, очень важно, чтобы они не пропускали события. Редкий промах (1 из тысячи?) — это нормально. Для базы данных в памяти, как процессы будут обновлять ее в базе данных, чтобы другие могли ее получить?   -  person user2511788    schedule 13.03.2016
comment
Конечно, с использованием сокетов unix, тогда это звездная топология.   -  person Antti Haapala    schedule 13.03.2016
comment
С помощью mmap() каждый процесс может одновременно пытаться выполнить запись на карту. Используйте примитив синхронизации, такой как мьютекс.   -  person n. 1.8e9-where's-my-share m.    schedule 13.03.2016
comment
как процессы будут обновлять его в базе данных, чтобы другие могли его получить: процесс-отправитель выполняет вставку/обновление в/в БД, а связанные таблицы будут иметь триггер вставки/обновления установлен, который, в свою очередь, будет отправлять новые данные другим 31 процессу.   -  person alk    schedule 13.03.2016

Ответы (1)


arrow_upward
1
arrow_downward

32 процесса в 32 сетевых пространствах имен уже довольно много, поэтому я думаю, вам нужно что-то серьезное и масштабируемое. Тогда я предлагаю вам использовать современную и масштабируемую систему Linux IPC.

  • Либо d-bus,

  • или netlink sockets (которые не ограничиваются сетевыми вещами и не будут мешать вашим пространствам имен, если вы этого не хотите ). См. здесь: "Протокол netlink представляет собой IPC на основе сокетов. механизм, используемый для связи [...] между самими процессами пользовательского пространства».

Это, безусловно, более тяжелая инфраструктура (с точки зрения работы по разработке программного обеспечения) по сравнению со старой школой IPC, такой как общая память, но вы получите следующие преимущества:

  • регистрация на мероприятия,

  • одноадресная/многоадресная/широковещательная связь между вашими процессами,

  • и гораздо меньше проблем с состоянием гонки.

РЕДАКТИРОВАТЬ:

Здесь чувствуется тенденция «да, это можно сделать с помощью обычного IPC Unix».

И да, конечно, это можно сделать. Это готово. Для вдохновения вы можете взглянуть на дизайн системы собственности Android, которые полагаются на простую разделяемую память и, похоже, были довольно успешными и масштабируемыми, не так ли? (и у вас даже есть исходный код под либеральной лицензией для изучения и разветвления - я использую это для встроенных продуктов, отличных от Android).

person jbm    schedule 13.03.2016
comment
Или, возможно, одного мьютекса будет достаточно для выполнения требований. - person n. 1.8e9-where's-my-share m.; 13.03.2016
comment
@н.м. Конечно. Как d-bus, так и netlink — довольно крутые вложения (код для записи, зависимости от libs, загрузка ЦП и объем памяти). Это зависит от того, как далеко хочет зайти ОП. Это детский проект или предполагается, что он станет огромным? - person jbm; 13.03.2016
comment
+jbm, можно ли использовать d-bus с несколькими серверами? Некоторая документация, кажется, подразумевает, что возможен только 1 сервер. еще раз спасибо, эти два варианта именно то, что я искал. - person user2511788; 13.03.2016