Взаимодействие между процессами

Тема в разделе "WASM.NETWORKS", создана пользователем cupuyc, 31 янв 2011.

  1. cupuyc

    cupuyc New Member

    Публикаций:
    0
    Регистрация:
    2 апр 2009
    Сообщения:
    763
    Здравствуйте. Мне нужно организовать обмен данными между процессами на одном компьютере. Вот думаю - может сокеты заюзать.. Суть в следующем: один процесс должен слать остальным некоторые данные (одни и те же данные для всех процессов - значение некоторой изменяющейся со временем переменной). Собственно вопрос по реализации. С TCP протоколом, я так понимаю, ничего не получится. Нужно юзать UDP и, видимо первый процесс должен посылать остальным широковещательные запросы. Так?
     
  2. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Можно сделать на: TCP, UDP, UDP Multicast, Shared Memory, Pipes, Mailslots, и прочие страшные слова. Все зависит от подробностей.
     
  3. cupuyc

    cupuyc New Member

    Публикаций:
    0
    Регистрация:
    2 апр 2009
    Сообщения:
    763
    _DEN_
    Задача такая:
    Есть некоторая межпроцессная глобальная переменная. Один процесс её периодически меняет, другие должны отслеживать эти изменения. Процессов может быть несколько, их количество может изменяться, могут создаваться новые, закрываться работающие. Если юзать SharedMemory, то главный процесс как-то должен уведомлять остальные о том, что он изменил значение переменной. С сокетами получается несколько проще - главный процесс просто передаёт значение этой переменной при её изменении, а остальные регистрируют их.
     
  4. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Не вижу ни одного преимущества сокетов в плане IPC перед теми же пайпами.

    Если бы данных было много и они имели бы нетривиальную структуру, то я бы предложил сделать этот один процесс pipe-сервером, остальные клиентами, пусть подключаются и получают свои данные. Это самое простое, что вообще можно придумать, потому что, как минимум, в этом случае не придётся думать о синхронизации, как, например, с шаренной памятью. Но у тебя одна там какая-то переменная (ULONG, я так понимаю?), тогда шаренная память будет лучшим выбором, не забудь только использовать интерлокеры для чтения/модификации. Для синхронизации используй семафоры, только помни, что ты должен точно знать, сколько читающих процессов у тебя будет.
     
  5. Y_Mur

    Y_Mur Active Member

    Публикаций:
    0
    Регистрация:
    6 сен 2006
    Сообщения:
    2.494
    cupuyc
    Непонятно - эта переменная что-то типа глобальной настройки или общего ключа?
    или у тебя модель системы сбора данных в реальном времени?
     
  6. cupuyc

    cupuyc New Member

    Публикаций:
    0
    Регистрация:
    2 апр 2009
    Сообщения:
    763
    Переменная типа ULONG, как правильно заметил x64. Она со временем изменяется. Другие процессы должны в реальном времени отслеживать её значение.
     
  7. Proteus

    Proteus Member

    Публикаций:
    0
    Регистрация:
    19 июн 2004
    Сообщения:
    344
    Адрес:
    Russia
    Com объект прилепи, с точкой подключения.. пусть уведомляет ...
    Корявое решение, но недостатков не видно...
     
  8. Booster

    Booster New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2004
    Сообщения:
    4.860
    Оповещение это уже другой вопрос. Можно заюзать Event.
     
  9. ntkernelspawn

    ntkernelspawn New Member

    Публикаций:
    0
    Регистрация:
    17 дек 2010
    Сообщения:
    61
    С TCP протоколом, я так понимаю, ничего не получится
    Это еще почему?

    Но лучше юзай pipes чем shared memory.
    - Абстрактней синхронизируются
    - Лучше расширяемость( изменения размера данных, поддержка 32 и 64)
    Ну и так далее..
     
  10. Y_Mur

    Y_Mur Active Member

    Публикаций:
    0
    Регистрация:
    6 сен 2006
    Сообщения:
    2.494
    cupuyc
    Как вариант рассылка сообщения WM_USER + ... через PostMessage HWND_BROADCAST ... . Главное не забыть зарегать своё сообщение в системе (RegisterWindowMessage) и продумать механизм узнавания клиентами кода этого сообщения (он в общем случае может быть разным даже от запуска к запуску сервера).
     
  11. cupuyc

    cupuyc New Member

    Публикаций:
    0
    Регистрация:
    2 апр 2009
    Сообщения:
    763
    Y_Mur, косяк в том, что сервер не знает каким окошкам слать эти сообщения. Слать всем окнам в системе через BROADCAST - совсем уж как-то косячно. Через окна, понятное дело, было бы проще всего.
     
  12. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Окна могут рассказать о себе при запуске.
     
  13. Y_Mur

    Y_Mur Active Member

    Публикаций:
    0
    Регистрация:
    6 сен 2006
    Сообщения:
    2.494
    cupuyc
    Насколько я понимаю если сообщение предварительно зарегистрировано, то максимум что произойдёт в остальных программах (только имеющих окна верхнего уровня) - один холостой цикл выборки сообщения из очереди, имхо не так уж это и косячно ;)
     
  14. cresta

    cresta Active Member

    Публикаций:
    0
    Регистрация:
    13 июн 2004
    Сообщения:
    2.257
    Лучше по другому: WM_USER + . HWND_BROADCAST отсылают клиенты при старте, прилепив к сообщению свои координаты (HWND).
    А сервер собирает у себя список клиентов (их HWND-ов) и конкретно знает, кому отсылать сообщения, не прибегая к BROADCAST.
    Клиент при закрытии (тем же способом, как и при запуске) уведомляет сервер, что он закрывается и нужно убрать его из списков
     
  15. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Клиент может грохнуться :) Лучше периодически слать "Yo-ho-ho! I'm alive!", и удалять из списка тех, кто не отметился вовремя.
     
  16. cresta

    cresta Active Member

    Публикаций:
    0
    Регистрация:
    13 июн 2004
    Сообщения:
    2.257
    _DEN_
    Это уже рабочий момент. Если клиент склонен упасть, то пусть при получении сообщения подтверждает, что принял. Будет ещё доп информация о том, что клиент работает, не завис.