Здравствуйте. Мне нужно организовать обмен данными между процессами на одном компьютере. Вот думаю - может сокеты заюзать.. Суть в следующем: один процесс должен слать остальным некоторые данные (одни и те же данные для всех процессов - значение некоторой изменяющейся со временем переменной). Собственно вопрос по реализации. С TCP протоколом, я так понимаю, ничего не получится. Нужно юзать UDP и, видимо первый процесс должен посылать остальным широковещательные запросы. Так?
Можно сделать на: TCP, UDP, UDP Multicast, Shared Memory, Pipes, Mailslots, и прочие страшные слова. Все зависит от подробностей.
_DEN_ Задача такая: Есть некоторая межпроцессная глобальная переменная. Один процесс её периодически меняет, другие должны отслеживать эти изменения. Процессов может быть несколько, их количество может изменяться, могут создаваться новые, закрываться работающие. Если юзать SharedMemory, то главный процесс как-то должен уведомлять остальные о том, что он изменил значение переменной. С сокетами получается несколько проще - главный процесс просто передаёт значение этой переменной при её изменении, а остальные регистрируют их.
Не вижу ни одного преимущества сокетов в плане IPC перед теми же пайпами. Если бы данных было много и они имели бы нетривиальную структуру, то я бы предложил сделать этот один процесс pipe-сервером, остальные клиентами, пусть подключаются и получают свои данные. Это самое простое, что вообще можно придумать, потому что, как минимум, в этом случае не придётся думать о синхронизации, как, например, с шаренной памятью. Но у тебя одна там какая-то переменная (ULONG, я так понимаю?), тогда шаренная память будет лучшим выбором, не забудь только использовать интерлокеры для чтения/модификации. Для синхронизации используй семафоры, только помни, что ты должен точно знать, сколько читающих процессов у тебя будет.
cupuyc Непонятно - эта переменная что-то типа глобальной настройки или общего ключа? или у тебя модель системы сбора данных в реальном времени?
Переменная типа ULONG, как правильно заметил x64. Она со временем изменяется. Другие процессы должны в реальном времени отслеживать её значение.
Com объект прилепи, с точкой подключения.. пусть уведомляет ... Корявое решение, но недостатков не видно...
С TCP протоколом, я так понимаю, ничего не получится Это еще почему? Но лучше юзай pipes чем shared memory. - Абстрактней синхронизируются - Лучше расширяемость( изменения размера данных, поддержка 32 и 64) Ну и так далее..
cupuyc Как вариант рассылка сообщения WM_USER + ... через PostMessage HWND_BROADCAST ... . Главное не забыть зарегать своё сообщение в системе (RegisterWindowMessage) и продумать механизм узнавания клиентами кода этого сообщения (он в общем случае может быть разным даже от запуска к запуску сервера).
Y_Mur, косяк в том, что сервер не знает каким окошкам слать эти сообщения. Слать всем окнам в системе через BROADCAST - совсем уж как-то косячно. Через окна, понятное дело, было бы проще всего.
cupuyc Насколько я понимаю если сообщение предварительно зарегистрировано, то максимум что произойдёт в остальных программах (только имеющих окна верхнего уровня) - один холостой цикл выборки сообщения из очереди, имхо не так уж это и косячно
Лучше по другому: WM_USER + . HWND_BROADCAST отсылают клиенты при старте, прилепив к сообщению свои координаты (HWND). А сервер собирает у себя список клиентов (их HWND-ов) и конкретно знает, кому отсылать сообщения, не прибегая к BROADCAST. Клиент при закрытии (тем же способом, как и при запуске) уведомляет сервер, что он закрывается и нужно убрать его из списков
Клиент может грохнуться Лучше периодически слать "Yo-ho-ho! I'm alive!", и удалять из списка тех, кто не отметился вовремя.
_DEN_ Это уже рабочий момент. Если клиент склонен упасть, то пусть при получении сообщения подтверждает, что принял. Будет ещё доп информация о том, что клиент работает, не завис.
