Я должен использовать WCF или неструктурированные сокеты?
Я хочу разработать клиент-серверное приложение в.NET, которая функционирует следующим образом:
- Клиенты соединяются с центральным сервером. Сервер должен отслеживать, которых соединяются клиенты, и он должен позволить только тем, которых он знает (у меня есть репозиторий разрешенных клиентов). Это вызвано тем, что в моем приложении, очень важно знать, кто все присутствуют в приведенном примере.
- Клиенты могли быть подключены к некоторым другим устройствам, сказать по LAN/USB/последовательным портам. Сервер должен смочь управлять этими подключенными устройствами через клиент. Например, давайте предположим, что клиент подключен к камере. Сервер должен смочь включить камеру в некоторое определенное время и затем возвратить изображения (или заставить клиент сделать это, и загрузите результат на сервер).
- Я также хотел бы способность, заставляют эти клиенты выполнить пользовательский исполняемый файл и получить результат. Например, сервер посылает заявление в (или вызывает некоторые существующие в), клиент, заставляет клиент выполнить его и возвращает получающиеся данные.
Я просто задаюсь вопросом, могу ли я использовать WCF с этой целью, или если я иду со старыми добрыми сокетами. Хотя начальная сеть была бы небольшой, я хочу, чтобы она масштабировалась (1000-е клиентов). Любое предложение значительно ценилось бы.
3 ответа
Сегодня я бы никогда не спустился на такой низкий уровень, как сокеты, если только вам это действительно не нужно. Работа с высокоуровневыми абстракциями намного продуктивнее и креативнее. Лучше потратить 2-3 дня на изучение WCF или .Net Remoting, чем 2 недели на отладку низкоуровневых сокетов.
Несколько недель назад у нас было похожее решение. Мы решили использовать Remoting, поскольку вы можете работать на уровне объектов, его чертовски просто настроить и довольно эффективно. Мы могли бы использовать WCF, но его было не так просто настроить.
Большим преимуществом Remoting или WCF является то, что вы можете передавать объекты между сервером и клиентом и вызывать методы на них на каждой стороне.
Предположим, вы написали абстракцию для вашей камеры, например:
class Camera
{
public CompressedImage GetFrame()
{
....
return image;
}
}
Тогда вы можете создать удаленный объект на сервере и написать что-то вроде:
var cam = SomeClientObject.GetCamera(); //get proxy object for the cam
....
var frame = cam.GetFrame();
что вызовет метод GetFrame() на клиенте и передаст вам изображение по (меж)сети, если изображение сериализуемо. Единственное, что вам нужно иметь в виду, это то, какие объекты создают прокси на другой стороне, а какие объекты копируются на другую сторону.
Это действительно мощно и работает для нас как шарм. Так что освободите свой разум от сокетов :)
Вы можете использовать WCF. Он позволяет делать обратные вызовы клиенту. начните здесь: http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx
И я также согласен с другим ответом: гораздо продуктивнее потратить несколько дней на оценку WCF вместо того, чтобы переходить на сокеты. В будущем вам понадобится получить множество функций, отсутствующих в сокетах... поэтому вам придется реализовывать их самостоятельно. В то время как WCF предоставляет их из коробки.
Я согласен с тем, что сокеты имеют очень низкий уровень, но, судя по описанию проблемы, вы хотите, чтобы сервер инициировал взаимодействие с клиентами в дополнение к обычному взаимодействию клиент -> сервер (т. Е. Клиент инициирован). Я также новичок в WCF и знаю, что WCF поддерживает двустороннюю связь. Но моя УГАДАЯ заключается в том, что когда клиент делает запрос, он также передает функцию обратного вызова, которую может вызвать сервер. Таким образом, модель по-прежнему клиент → сервер, за которым следует сервер, вызывающий обратный вызов.
Связь, инициированная сервером с WCF, - это то, о чем я не знал . Так что вы можете проверить это, прежде чем выбрать один из двух.
Вы также можете рассмотреть комбинацию обоих, например, WCF для большинства сценариев, и отдельного потока, обрабатывающего Socket Communication, для тех случаев, когда WCF не подходит / не возможен.
Спасибо
VM