Имеется следующая архитектура: клиентская часть(dll-ка на C#) отсылает определенное количество картинок на сервер(либо Windows Service, либо Web Service), где они обрабатываются, а потом отсылается ответ в виде XML файла результатов обработки.
Клиент - это просто автоматизированное приложение, без интерфейса и ввода вывода.
Сервер. На нем крутится движок, использующий многопоточность (с помощью ThreadPool) для обработки картинок.
Соответственно, когда обращается новый клиент, сервер создает новый поток, в котором происходит обработка, по окончанию он отсылает ответ пользователю(xml-файл).
Нагрузка на сервер планируется не очень большая 3-20 одновременных подключений.
Пока что я не могу понять какая архитектура взаимодействия лучше всего подойдет для моего случая. Есть несколько путей реализации, либо писать асинхронный сервер на сокетах, либо использовать WCF, или просто написать ASP.NET приложение и залить его на IIS(к этому варианту я склоняюсь больше всего).
Какой протокол передачи лучше всего использовать? Хватит ли HTTP для передачи большого количества картинок(тогда можно двигаться в направлении Web Service), или стоит задуматься о TCP/IP(здесь уже WCF)?
Кому интересно, несколько статей по созданию клиент-серверного приложения:
Example with ASYNC/AWAIT
Example with THREADS
Example with SOCKETS
Ответ
HTTP, WCF и голый TCP справляются с заливкой картинок примерно одинаково.
Особенно если учесть, что HTTP работает поверх TCP, а WCF - или поверх HTTP, или с собственным протоколом поверх TCP, в зависимости от настроек биндинга.
Никакой ощутимой разницы между реализациями с точки зрения производительности не будет.
То же самое с типом хостинга - между Self-Hosted и IIS нет практически никакой разницы (не при вашей нагрузке).
Вам стоит использовать то, что вам удобнее в написании и поддержке.
Комментариев нет:
Отправить комментарий