Есть exe, он при старте стартует другой ехе и подгружает ему длл, слбсно как наиболее оптимально организовать обмен данными причем более мение синхронный т.е. длл говорит ехе когда что делать пока мысля с помощью оконных сообщений, но возникает сложность с обменом кусков памяти например строк. Была мысля отпровлять сначало строку а потом сообщение что с ней делать, но как то это слишком надуманн. Жду ваших предложений.
мейлслот для обмена именами пайпов двунаправленный пайп для обмена непосредственно информацией (по типу сокетов)
MSoft Медленно это. LPC быстрее в разы. А лучше выполнять обмен через разделяемую память с синхронизацией по эвентам.
Создаешь 1 мейлслот и через него обмениваешься именами пайпов. Потом на одном конце создаешь такой пайп, а на другом - коннектишься к нему. И дальше просто отправлешь в него инфу. "+" этого метода - интерфейс как у привычных блокирующихся сокетов. Про метод Clerk ничего сказать не могу, т.к. не понял, о чем он
LPC просто, если слишком высокая скорость не нужна используй этот механизм, он используется при любых действиях с консолями к примеру. Если нужно бысро очень, тогда создай именованную секцию(обьект секция, именованная или нет зависит от тебя), спроецируй в оба процесса это и будет канал через который будут передаваться данные. Для синхронизации - один либо два эвента, именованные или нет также зависит от тебя.
Clerk твой метод, я так полагаю, подходит только для 2-х процессов, так? моим может пользоваться неограниченное* количество клиентов и 1 сервер
Вы еще подеритес ьгорячии финские парни ) Clerk Да мысля обмениваться через общию секцию данных сейчас расматриваеться, просто понимаете у меня в основном короткие строки, не будет ли это из пушки по воробьям. Кстате я не понял как вы предлагаетесообщать программа когда пора обрабатывать данные?
SPA Поток принимающий данные ждёт на евенте(с автосбросом) в NtWaitForSingleObject. Поток передающий данные записывает их в секцию, сигнализирует евент и ждёт его. Поток принимающий данные выйдет из состояния ожидания и считает данные из секции, обработает их и запишет результат в секцию, затем сигнализирует евент и снова его ждёт. Поток передающий данные выйдет из состояния ожидания и считает ответ.
Clerk А спасибо понял... благодарю за помощь, думаю хороший вариант, лучше оконных сообщений ) Ща пощу доку про именнованые секции, я с ними не работал еще. MSoft тоже спасибо, но в моем случае правда надотолько для 2х поцессов
all Вот какой у меня вопросик то остался, мне самомму в потоках которые ждут придеться смотреть для меня он или нет, так. Просто при SetEvent не извесно какому потоку передасться инфа, поэтому надо смотреть мне это или не мне. Так? я думаю просто байтик в начале памяти и усе.
а и еще я говорю про метод с секциями и обьектами, а что такое LPC, но это не важно мне понравился метод с памятью/обьектами
LPC - Local Procedure Call. Сервер создает порт (ZwCreatePort), начинает слушать порт (ZwReplyWaitReceivePort,..) затем клиент может приконектится к порту (ZwConnectPort,..) используя его идентификатор, сервер и клиент могут начать обмен сообщениями (ZwRequestWaitReplyPort,..) в которых помимо заголовка, можно передавать данные небольшого размера для передачи данных большого размера, предусмотрен механизм с разделяемой секцией.
ну не обязательно так, можно просто создать безымянный порт, сделать дубликат хендла порта и передать его другому процессу. тогда не потребуется коннект или акцепт.
Только для передачи больших объемов данных придется секцию проецировать в оба процесса самому, а так ядро все за нас сделает
А можно как-то по-проще организовать обмен между двумя процессами? Реально нужно передать одно значение!)