-1

Требование - это возможность «общаться» между двумя консольными приложениями в одном окне. Я реализовал это с использованием именованных каналов, реализуя как функцию отправителя, так и получателя в каждом приложении.Обмен текстовыми сообщениями между двумя процессами на ящике с использованием файла с памятью

Я хочу использовать эту же функциональность, но используя файлы с памятью Mapped (хотя я думаю, что это не идеальна для общения типа чата).

Для простоты говорят, что сообщения чата - это просто короткие строки.

Вот что я имею в виду:

Одно приложение будет заботиться о создании взаимной блокировки и памяти отображается файл. Назовите его мастером.

В каждом приложении мы поддерживаем два потока, один отвечает за ввод пользователя ввода и записи в файл, а другой ответственен за периодически , проверяя, есть ли у него что-то для чтения.

Таким образом, четыре потока во всех, каждый из которых управляется мьютексом для доступа к файлу .

Внутри файла, я думаю, что оба должны иметь свой собственный раздел. скажем первая половина размера файла для главного приложения, а другая половина для второе приложение.

Поэтому, когда пользователь вводит строку текста в главном приложении, поток обращается к своей половине файла и пытается добавить новый текст после последней новой строки .

Когда приложение читает свой раздел файла для текста, если оно есть, приложение читает его и разрывает его раздел.

Правильно ли этот подход? Другим подходом было бы к тому, как отметить сообщение с исходным идентификатором, чтобы читатель знал, что игнорирует сообщения, которые написаны сами по себе. Но я чувствую, что это ненужный синтаксический анализ строк.

Кроме того, каждый поток считывателя периодически пытается прочитать их раздел файла, чтобы узнать, есть ли новые данные, можете ли вы предложить какой-либо механизм уведомления? Вид обработки событий? Читательский поток будет искать только новые сообщения, если он получит какое-то уведомление о событиях.

Любые мысли?

+1

Это не идеальный длинный выстрел. Сообщения соответствуют протоколу потока. Изначально канал очень хорошо покрыт именованным каналом, сокет и очередь сообщений. –

+0

@ HansPassant Я знаю, что это не идеально. Но если вы ограничены использованием одного файла, связанного с памятью, каким будет подход? – Brian

+1

Если я ограничусь такими необоснованными техническими выборами, не скажу в этом вопросе, я бы прекратил работу. –

ответ

1

Я согласен с Хансом по большей части, файлы с отображением памяти не были бы идеальными здесь, если вы идете по этой дороге, хотя подумайте об использовании названного события (см. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682396(v=vs.85).aspx) вместо опроса.

Возможно, вам понадобится p/invoke, чтобы получить эту функциональность из C#.

В остальном каждому приложению присваивается свой собственный регион файла, а секция управления управляется мастером для координации того, кто что получает.