Вечер добрый.
Задача такая:
Мое приложение не может быть запущено одновременно в двух терминальных сессиях на одном сервере. При помощи создания event-а я определяю, что это приложение уже запущено — в другой терминальной сессии или в этом же сеансе. Теперь мне надо послать сообщение (postMessage) окну приложения, чтобы оно закрылось. Есть ли возможность послать его при запущенном Terminal Services?
P.S. Можно было бы конечно установить "the specified event object to the signaled state", а приложение бы по этому событию закрывалось бы. Но мне надо передать строку вида "Тебя закрывают из-за такого-то". Так что postmessage был бы лучшим вариантом.
Здравствуйте, akatik_jr2, Вы писали:
_>Вечер добрый. _>Задача такая: _>Мое приложение не может быть запущено одновременно в двух терминальных сессиях на одном сервере. При помощи создания event-а я определяю, что это приложение уже запущено — в другой терминальной сессии или в этом же сеансе. Теперь мне надо послать сообщение (postMessage) окну приложения, чтобы оно закрылось. Есть ли возможность послать его при запущенном Terminal Services?
Я так понял, можно ли послать сообщение окну из другой сессии ? AFAIK нет.
Но можно сделать, скажем, общий mmf, через него обмениваться информацией, а приказ "прочти информацию" сделать на том же ивенте.
Здравствуйте, akatik_jr2, Вы писали:
_>Теперь мне надо послать сообщение (postMessage) окну приложения, чтобы оно закрылось. Есть ли возможность послать его при запущенном Terminal Services?
Нет такой возможности. Сообщение окну нельзя послать даже окну на другом десктопе в той-же сеансе, а между терминальными сеансами вообще никакие не проходят. Выбирайте любой IPC — COM, пайпы, сокеты, но не MMF, если конечно не стоит задача запускать приложение только под админом.
JR>Нет такой возможности. Сообщение окну нельзя послать даже окну на другом десктопе в той-же сеансе, а между терминальными сеансами вообще никакие не проходят. Выбирайте любой IPC — COM, пайпы, сокеты, но не MMF, если конечно не стоит задача запускать приложение только под админом.
Гм, а чем MMF не угодили ? В рамках постановки задачи требуется лишь, чтобы файл, на базе которого пойдет передача сообщений, был один и тот же. Общее имя для мэппинга и расположение его в Global совсем не обязательно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Гм, а чем MMF не угодили ? В рамках постановки задачи требуется лишь, чтобы файл, на базе которого пойдет передача сообщений, был один и тот же. Общее имя для мэппинга и расположение его в Global совсем не обязательно.
Насколько я понимаю фразы
не может быть запущено одновременно в двух терминальных сессиях на одном сервере
и
Теперь мне надо послать сообщение (postMessage) окну приложения, чтобы оно закрылось.
задача стоит такая
1) Обнаружить уже запущенный экземпляр в другой терминальной сессии
2) Передать ему команду.
Если использовать MMF для передачи команды, необходимо, чтобы этот MMF был виден в обоих сеансах, а для этого его необходимо создать в Global Namespace, для чего, в свою очередь, нужна SeCreateGlobal. Нет? Плюс к тому потребуется механизм уведомлений о том, что команда размещена в MMF. Но если команда — одна-едениственная и не требует передачи доп. параметров, то надобность MMF совсем пропадает, уведомление и будет самой командой.
Однако построить такую систему с необходимым уровнем надёжности на одних объектах типа семафора или эвента в условиях терминального сервера вряд-ли возможно, и в любом случае потребует неоправданного усложнения.
Из всего изложенного, по-моему, и следует вывод, о необходимости использования полноценного IPC со встроенной системой уведомления получателя. К вышеуказанным я-бы, пожалуй, добавил Mailslots, причём как наиболее удобные в данном случае.
Здравствуйте, Jolly Roger, Вы писали:
JR>Если использовать MMF для передачи команды, необходимо, чтобы этот MMF был виден в обоих сеансах, а для этого его необходимо создать в Global Namespace, для чего, в свою очередь, нужна SeCreateGlobal. Нет? Плюс к тому потребуется механизм уведомлений о том, что команда размещена в MMF. Но если команда — одна-едениственная и не требует передачи доп. параметров, то надобность MMF совсем пропадает, уведомление и будет самой командой.
Не вполе ясно, почему все же в Global. Здесь явно отсутствует необходимость когерентности, а больше Global ничего не дает. Если файл один и тот же, а спусковым крючком является ивент, то совсем не обязательно, чтобы это был один и тот же объект ядра. Этот MMF может быть в каждом процессе свой, но на базе одного и того же файла.
В конце концов можно ведь просто на базе файла сделать — один пишет, другой читает, тут уж вопрос о Global видимости уходит вообще. А MMF просто удобнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не вполе ясно, почему все же в Global. Здесь явно отсутствует необходимость когерентности, а больше Global ничего не дает. Если файл один и тот же, а спусковым крючком является ивент, то совсем не обязательно, чтобы это был один и тот же объект ядра. Этот MMF может быть в каждом процессе свой, но на базе одного и того же файла.
PD>В конце концов можно ведь просто на базе файла сделать — один пишет, другой читает, тут уж вопрос о Global видимости уходит вообще. А MMF просто удобнее.
Я не понял, чем в описанной Вами схеме MMF удобней, и зачем он тут вообще нужен.
А учитывая, что необходимо предусмотреть ситуацию, когда несколько экземпляров должны будут договориваться о том, кому из них оставаться, а кому помирать, я нормальной альтернативы полноценному APC не вижу.
Впрочем, здесь уже вступают в силу личные предпочтения, а учитывая, что ТС потерял к вопросу интерес, вряд-ли стоит продолжать.
JR>>К вышеуказанным я-бы, пожалуй, добавил Mailslots, причём как наиболее удобные в данном случае. JR>Хотя, по здравом размышлении, Mailslots, пожалуй, здесь будут вряд-ли удачным выбором.
А почему?
Получается красивая схема: запускаем программу — пытаемся создать этот самый майлслот. Если не создается — значит другой экземпляр программы уже запущен. Открываем майлслот и посылаем ему сообщение "Выйди вон. Сказал такой-то".
Что не сработает?
Здравствуйте, akatik_jr2, Вы писали:
_>А почему? _>... _>Что не сработает?
Я думаю, проблемы возникнут, когда "одновременно" в нескольких сессиях будет произведена попытка запуска этого приложения. Возникнет ситуация, когда им придётся как-то договориться, кто останется, для чего потребуется обмен, то есть каждый из экземпляров должен иметь возможность получать данные от остальных. Mailslot-же, ЕМНИП, штука однонаправленная, у неё может быть много отправителей и только один получатель. Если-бы задача стояла так: "Кто первый создал объект, тот и остаётся жить", то всё было-бы значительно проще, но ТС указал противоположное требование:
...я определяю, что это приложение уже запущено — в другой терминальной сессии или в этом же сеансе. Теперь мне надо послать сообщение (postMessage) окну приложения, чтобы оно закрылось.
"Нормальные герои всегда идут в обход!"
