- Suslik
- Постоялец
Всем привет.
Возникла необходимость передать немного данных из одного процесса в другой, оба процесса мои. Необходимо это сделать наиболее безболезненно в первую очередь для программистов, которые будут пользоваться моим кодом. Я знаком и много работал с IPC под юниксами: pipe, fifo, socket'ы, system V ipc(msg queue, shared memory, semaphore'ы), file mapping, signals. К сожалению, мои знания в этой теме гораздо более академические, чем практические - я умею этим пользоваться, но не знаю, что из этого реально применяется. Под виндой вообще имел дело только с сокетами.
Поэтому вопрос: какую технологию выбрать для передачи данных под виндой, чтобы она была наименее экзотичной? Огромного объёма передаваемых данных не требуется, планируется передавать несколько сотен байт в секунду. У меня уже есть зависимость от SFML, который умеет сокеты и мьютексы, наверное, ими было бы удобнее всего воспользоваться, но не overkill ли это? И ещё, как в таком случае избежать проблем с коллизией номеров портов для localhost'а?
Suslik
Хм, а твои программы окна имеют? Потому что у винды есть стандартный механизм передачи произвольных данных окну другого приложения. Подробнее гляну завтра. Механизм на чистом WinAPI, прост как двери - функция отправки, ну и приём в цикле обработки сообщений окна.
Bishop
да, я знаю, это через сообщения. но нет, окон нету.
Suslik
> shared memory
> file mapping
Юзай или то, или другой.
Это самый быстрый способ передачи данных из одного процесса другому.
С shared memory больше возни в плане настроек компилятора и линкера. Смысл в том, что при загрузке DLL или EXE система сразу создает кусок памяти для всех процессов.
С file mapping проще всего. Проще всего организовать очередь сообщений (как на прием так и на передачу). Проще всего реализовать атомарный доступ к данной памяти через Interlocked-функции и Events.
Всё остальное (мютексы и т.п. тормозить систему будут).
Suslik
> SFML ... но не overkill ли это?
Имхо не больше, чем когда он (SFML) используется для других целей. Зато можно быстро закрыть проблему.
Ну или курить WinAPI :)
А в чём проблема портов? Есть сервер - застолбил для него некий номер и пользуешься.
По факту невозможности открыть/создать порт можно и single-instance сервера поддерживать.
rcsim
> А в чём проблема портов?
в том, что я не в курсе, как выбрать гарантированно не занятый для сервера.
asvp
какими свойствами оно обладает и как работает я в курсе. как ими пользоваться - разберусь. вопрос в том, что из этого считается использовать нормально.
Suslik
> вопрос в том, что из этого считается использовать нормально.
Нормально - понятие растяжимое.
Ну если, socket'ы заюзать ради передачи 100 байт/сек. между процессами на одной машине - это не нормально.
shared memory или file mapping - это нормально. Именно на этом работают остальные IPC.
пайпы есть CreateNemedPipe
Suslik
> вопрос в том, что из этого считается использовать нормально.
да всё нормально под свою задачу.
наиболее простыми здесь наверное будут пайпы... хотя опять таки надо знать специфику задачи.
а вот сокеты здесь как раз пожалуй черезчур.
А если через #pragma data_seg ?
А вообще, помнится, в одном проекте у нас эмулировался прибор именно через File Mapping, - всё замечательно работало, как с настоящим железом/драйвером. И никаких конфликтов, потому что имя файла сам выбираешь.
0iStalker
> А если через #pragma data_seg ?
Это относиться к shared memory
Вообще Pipe наверное лучше всего
а вообще
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx
но есть еще и специфичные вещи типа
https://technet.microsoft.com/ru-ru/library/cc732184.aspx
оно правдо идет отдельной службой, и его нужно включать специально... если я не ошибаюсь
Suslik
> о нет, окон нету.
А можно создать, ага. Никаких коллизий портов. Ну а вообще я за именованные пайпы
Тема в архиве.