Какие технологии использоватль для клиент-серверного приложения .NET?

Question

[r1zar]

Добрый день,
подскажите какие технологии использовать для создания сервера, рассчитанного на большое количество клиентов с помощью .NET. Интересует построение масштабируемого, распределенного серверного приложения. Очень желательно, чтобы поддерживались Mono. До этого использовал только голые сокеты, но, думаю, они не подойдут. Подскажите книги/статьи, вообще, в какую сторону смотреть.

Answer 1

[bobermaniac]

WCF

Answer 2

[Андрей Поляков]

Голые сокеты это самый гибкий вариант — напишите именно то, что вам нужно! Задача довольно сложная, но вполне решаемая, особенно если сначала подумать, а потом писать код.

WCF очень неплохой вариант — всё написано за вас, но максимума производительности не получить, да и с взаимодействием с не .Net могут быть проблемы, если об этом не задумываться. Я бы посоветовал на начальном этапе использовать именно его.

Посмотрите также в сторону google protocol buffers в качестве подспорья по оптимизации сетевого обмена. Его можно использовать как с WCF, так и на голых сокетах. Снимает головняк по вопросам подготовки данных перед отправкой в канал.

Comments

[Андрей Поляков]

Да, забыл написать. Если хотите 100% работы на Mono, то WCF практически не вариант, т.к. в настоящий момент там реализовано не всё.

[r1zar]

А как с сокетами происходит масштабируемость? Как на нескольких машинах запустить сервер?

[Андрей Поляков]

Вопрос масштабируемости очень сложный. Решать его не зная особенностей проекта невозможно. Если у вас будет staless приложение, то вопрос запуска нескольких серверов решается очень просто — запускаете несколько серверов с подключением к одной БД и каким либо образом распределяете клиентов между ними (самый простой способ DNS).
Если приложение statefull, то уже нужно сильно думать, а если БД станет узким место, то думать нужно будет ещё больше.

[r1zar]

Как один из вариантов — 1 управляющий сервер, который перекидывает клиента на наименее загруженный сервер из доступных. Можете сказать чем хорош/плох подобный вариант?

[Андрей Поляков]

Хорош тем, что позволяет реализовать любую политику распределения клиентов.
Условные недостатки:
1. Нужен ещё один сервер
2. Нужно эту логику писать

Answer 3

[z130]

Webservice тоже может быть сойдет — проблем с разными платформами тут точно не будет, объекты прозрачно сериализуются в понятный глазу XML.
Но, нужно смотреть ваш протокол обмена — все-таки webservice не заточен под непрерывное удержание канала связи с клиентом.
По масштабированию, если все-таки будет тормозить фронт — просто поставите несколько серверов.
А Mono вам зачем — на лицензии Windows сэкономить?

Comments

[r1zar]

Mono — для запуска на любых платформах, возможно будет использоваться GNU/Linux или OS X Server.

[z130]

Про Linux понятно, если вдруг у Заказчика нет Windows на продакшене.
А вот живой OS X Server вы вообще видели? Страшный у вас Заказчик, если у него парк таких серверов есть ))

Answer 4

[Gwynbleidd]

Возможно, вам подойдет .NET Remoting, хоть он и считается устаревшим.
С ним проблем на Mono поменьше, чем с WCF. Хоть WCF всяко предпочтительнее выглядит.