Несколько клиентов Linux IPC с демоном

Это действительно просто, но я сейчас ничего не понимаю.

У меня есть процесс-демон, и я хотел бы, чтобы несколько клиентов могли с ним общаться. Я хотел бы, чтобы клиент мог запуститься, а затем, используя общую библиотеку, по существу «зарегистрироваться» в процессе демона. Процесс демона порождает поток для этого нового клиента и обеспечивает канал связи между клиентом и новым потоком.

Я думаю о сокете дейтаграммы unix как о «канале регистрации» для всех клиентов, который они используют изначально, а затем переключаются на канал, специфичный для клиента, но затем не могу понять, как я создаю уникальные имена для новых сокетов дейтаграмм, не настраивая их априори. .

  • Сервер и клиенты находятся на одной машине, предпочитают использовать сокеты дейтаграмм, чтобы не разбивать поток на пакеты.
  • Будет отправлять (очень) высокоскоростные небольшие сообщения туда и обратно.

linux ipc unix-socket
person RishiD    schedule 04.12.2012    source источник
comment
Я думаю, вам не нужно ничего особенного. Один доменный сокет может принимать несколько клиентов, просто начните общаться на нем. Это stackoverflow.com/questions/9644251/ может быть дубликатом.   -  person MK.    schedule 05.12.2012
comment
Я не могу использовать один сокет для общения с несколькими клиентами, верно? Мне все равно пришлось бы создать какой-то протокол согласования, чтобы настроить вторичный сокет, чтобы разрешить потоку сервера общаться только с одним клиентом.   -  person RishiD    schedule 05.12.2012
comment
Я думаю, что каждый accept возвращает новый файловый дескриптор   -  person MK.    schedule 05.12.2012
comment
Это только для сокетов (AF_UNIX, SOCK_STREAM), а не для DGRAM, что заставит меня добавить заголовок к моим сообщениям, а затем разбить поток на пакеты в коде приема. Сокеты дейтаграмм Unix должны иметь имя, связанное с ними перед привязкой.   -  person RishiD    schedule 05.12.2012
comment
хорошо, теперь я понимаю, о чем вы говорите. Я посмотрю на свою копию Стивенса.   -  person MK.    schedule 05.12.2012

Ответы (2)


arrow_upward
2
arrow_downward

По сути, я думаю, вам нужно пойти на компромисс и иметь двухэтапный процесс с сокетом SOCK_STREAM в качестве этапа 1 и SOCK_DGRAM в качестве этапа 2. Таким образом, это будет так:

сервер:

  1. создать сокет SOCK_STREAM "my.daemon.handshake"
  2. принять клиента
  3. отправьте случайно сгенерированную строку XXX клиенту и закройте сокет
  4. создайте сокет SOCK_DGRAM "my.daemon.XXX" и начните его обработку
  5. повторить (2)

клиент

  1. подключиться к сокету "my.daemon.handshake"
  2. прочитать в EOF -- получить значение XXX

  3. начать общение с сервером на сокете "my.daemon.XXX"

  4. выгода!!!!

person MK.    schedule 05.12.2012
comment
Да, это единственная схема, которую я мог придумать, но она такая «уродливая». Это должно быть относительно обычным явлением в стране Unix; Я мог бы просто стиснуть зубы и использовать локальные STREAMS только для автоматического создания дескриптора файла для каждого соединения. - person RishiD; 05.12.2012
comment
Я не знаю. Это не кажется мне супер-уродливым. Вы всегда можете использовать какую-нибудь абстракцию более высокого уровня, такую ​​как RabbitMQ, ZeroMQ или, возможно, даже dbus. - person MK.; 05.12.2012

arrow_upward
4
arrow_downward

Вы можете полностью избежать проблемы именования клиентских сокетов, если хотите. Каждый клиент может создать подключенную пару сокетов, используя socketpair(). Затем клиент отправляет один из дескрипторов сокета на сервер по вашему хорошо известному «каналу регистрации». Затем у сервера и клиента есть частная, подключенная, безымянная пара сокетов для их связи.

Дескриптор сокета отправляется на сервер с помощью sendmsg() и заполнения управляющего сообщения msg.

Эти два ответа имеют соответствующую информацию/ссылки:

Как мне использовать сокет, чтобы несколько процессов взаимодействовали с центральным процессом?

Отправка файлового дескриптора через доменный сокет UNIX и выбор()

person Ted Stockwell    schedule 05.05.2013