Windows Forms & WCF - Связь с клиентскими приложениями - PullRequest
1 голос
/ 17 июля 2009

Мы разрабатываем приложение для Windows Forms, которое будет установлено на 1000 сотрудников. Пользователи могут запускать несколько экземпляров приложения одновременно. Все клиенты находятся в одной интрасети.

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

Наша команда рассказала о двух разных подходах:

1. Многоадресные пакеты

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

Мой вопрос на данный момент: как клиент узнает, что он не получил пакет? (не знаю, чего вы не знаете) Что приводит нас к журналу событий с временными метками в базе данных, а элементы управления пользовательским интерфейсом отслеживают время последнего обновления. Они попадают в фокус, проверяют свои временные метки и обновляют по мере необходимости.

Кто-то еще сказал, что элементы пользовательского интерфейса будут просто перезагружаться каждый раз, когда они попадают в фокус (подумайте о режимах в перспективе, перенося элементы управления в начало рабочей области стека с CAB). И что многоадресная рассылка предназначена для обновления клиентов, что их текущий контекст изменился. Если они пропускают это, они работают с устаревшими данными, пока они не изменят режимы и не вернутся.

2. WCF и обратные вызовы

Клиенты регистрируются в контрактах WCF для обратных вызовов через привязку tcp. Основной технической проблемой является сервер, поддерживающий множество открытых сокетов. Мы прочитали о том, как он не открывается в традиционном смысле, его усыпляют максимум на 90 секунд, а затем восстанавливают в этот момент. Мы также читаем о максимальном количестве открытых соединений, которое может обрабатывать компьютер с Windows 2003 Server, и о том, как изменить это в реестре.

Если у нас есть 1000 соединений с открытым сокетом к серверу, это развалится?

Если кто-то сталкивался с такой же ситуацией и попробовал или оценил подход WCF, мы хотели бы услышать об этом.

1 Ответ

1 голос
/ 17 июля 2009

Я не реализовал подобную ситуацию. Однако я думаю, что одна из дуплексных привязок не обязательно будет иметь высокие издержки.

Все зависит от того, сколько информации сервер должен отправить клиентам. Я понимаю, что вы сказали, что информация будет использована для обновления их интерфейса. Однако представляется вероятным, что им может не понадобиться одинаковое количество информации в одно и то же время. Например, если информация о западном регионе изменилась, все 1000 клиентов могут захотеть узнать, что есть изменение, и все они могут захотеть обновить сводную информацию о западном регионе, но, возможно, только 1/4 из них может нужно увидеть детали изменения.

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

При необходимости вы можете пакетно обновлять вместе. Если клиенты должны обновляться только один раз в секунду, вы можете накапливать изменения за последнюю секунду и отправлять их все сразу.

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

...