Вы должны избегать архитектуры, которую вы рассматриваете. Объединить два отдельных процесса для совместной работы сложно. Операционная система создает большую стену между процессами, чтобы гарантировать, что один неправильный процесс не может дестабилизировать другой. Каждый процесс имеет свое собственное представление о памяти, Windows (и особенно .NET) сильно затрудняет совместное использование памяти процессами.
Вам нужно установить канал связи между процессами, чтобы заставить их работать вместе. Труба или розетка - это обычный выбор, ментальная модель здесь - это машины, разговаривающие друг с другом по сети. Это может быть очень неудобно, у вас есть все недостатки веб-приложения, ни одно из преимуществ клиента WinForms или приложения в консольном режиме. Это также очень ненадежно, сбой одного процесса трудно диагностировать, сообщить и восстановить другим приложением. Я уверен, что вы видели, что может пойти не так с использованием вашего интернет-браузера.
Вы можете получить то, что вы хотите из одного приложения. Класс System.Threading.Thread дает вам моральный эквивалент вашего приложения в режиме консоли. Получить интерфейс для отображения сообщений из мозгового потока довольно просто с помощью класса BackgroundWorker или метода Control.Begin / Invoke (). Только «честно» между прочим, добиться правильного взаимодействия потоков все еще сложно.
Существует два способа реализовать обновление биржевого тикера. Толчок против подхода притяжения. Метод принудительной отправки позволяет фоновому потоку активно уведомлять поток пользовательского интерфейса о наличии обновления. BackgroundWorker.ReportProgress или Control.Begin / Invoke для этого. При обновлении 200 мс это не проблема.
При таких показателях модель pull будет работать так же хорошо. Вы бы использовали Timer в пользовательском интерфейсе, чтобы периодически запускать метод. Он может прочитать значение из общего свойства в методе Tick таймера. Вам нужно будет использовать оператор блокировки как в фоновом потоке, так и в методе Tick, чтобы гарантировать, что значение не может измениться, так как поток пользовательского интерфейса читает значение.
Следует отдавать предпочтение модели извлечения, когда значение может изменяться очень быстро, нажимая со скоростью, которая поставит поток пользовательского интерфейса на колени, когда время, необходимое для обновления пользовательского интерфейса, больше, чем период между обновлениями из фонового потока. Поток пользовательского интерфейса будет отставать и не будет выполнять свои обычные обязанности. Замороженный интерфейс - это диагностика, а OOM - конечный результат. 200 мсек не должно быть проблемой, если вы не очень увлекаетесь обновлениями пользовательского интерфейса или неаккуратны, push должен работать.
Мне нужно присоединиться к лиге друзей, с которыми вы консультировались по поводу серверов telnet. Не зная, какую проблему они решают, они являются эквивалентом веб-сервера 1990 года, когда все использовали терминал с зеленым экраном для общения с компьютером. Возможно, это относится к необходимости подключения отдельного приложения в режиме консоли к приложению пользовательского интерфейса. Вы не будете использовать telnet для этого, сокет - это общий канал. .NET Remoting или, что еще лучше, WCF - это слой, который расположен поверх этого канала, чтобы избежать необходимости сталкиваться с трудностями сжатия данных или параметров метода через канал байтов. Продолжайте, если вы уже полностью включены в многопроцессное решение. Вы не должны подходить для биржевого приложения, никому нет дела до того, как они будут работать, если на них никто не смотрит. Падение дерева в лесу, возможно.