Basil A. SidorovАлексей ВахтинПри этом нужно сделать так, чтобы они подключались к серверу, через этот сервер находили друг друга и передавали бы данные. Как сделать используя сервер понятно - на сервер отправить, сервер передаст по адресу назначения, но тогда сервер может оказаться перегруженным.Простое копирование данных из сокета в сокет - операция не ресурсоёмкая. Ага... Совсем "не ресурсоемкая"... И таких понятий как DoS (Denial of Service) и DDoS (Distributed Denial of Service) в природе не существует...

Basil A. Sidorovsphinx_mv Ага... Совсем "не ресурсоемкая"...У вас есть другие оценки или просто прицепиться?Не порите чушь - никто к Вам цепляться не будет...
Вам что-нибудь говорят ограничения максимального количества устанавливаемых одновременных сетевых соединений?
А про лимиты скорости подключения сетевых интерфейсов (включая технические)?
Про ограниченую производительность отдельного процессора/компьютера/сервера даже не буду заикаться...
Basil A. SidorovИ таких понятий как DoS (Denial of Service) и DDoS (Distributed Denial of Service) в природе не существует...Ну и каким это боком к штатной работе сервиса?Ну, и в каком же месте заканчивается "штатная" работа и начинается "аут оф сервис" - у Вас самого внятный критерий есть?
Хотя, откуда ему взяться - у Вас же "задача не ресурсоемкая", и любой сервер можно "нагружать до бесконечности"... Ага...

Basil A. Sidorovsphinx_mvНе порите чушь - никто к Вам цепляться не будет...Без комментариев.Вам что-нибудь говорят ограничения максимального количества устанавливаемых одновременных сетевых соединений?
А про лимиты скорости подключения сетевых интерфейсов (включая технические)?
Про ограниченую производительность отдельного процессора/компьютера/сервера даже не буду заикаться...Если до вас очень туго доходит, то я поясню: было предложено использовать простейший вариант.Так ЭТО у Вас "простейший вариант"?!
Ну, а то, что Ваш "простейший варант" будет работать только в "простейших условиях" - это Вам еще предстоит самостоятельно дорасти... Например, когда появится пара десятков-пара сотен-хотя бы тысяча одновременных активных подключений к серверу...
Basil A. SidorovЯ знаю , что это вариант не ресурсоёмок, я знаю как оптимизировать такую передачу и как решать типичные проблемы типа "разноскоростные клиенты" или "вот эти данные нужно раздать нескольким клиентам".
Человек, который говорит, что знает все, на самом деле не знает ничего. (с) - очень точно Вас характеризует.
Вы НЕ знаете, СКОЛЬКО (и КАКИХ) ресурсов использует Ваше решение - соответственно, оптимизировать Вам НЕЧЕГО.
И просто ЗНАТЬ, как решаются типичные проблемы, и УМЕТЬ решать типичные проблемы - это весьма разные вещи...
Basil A. SidorovЯ не знаю це-шарп, но предложенный вариант от языка не зависит.
А это Вы к чему?
Basil A. SidorovP.S. Прежде чем решать проблемы типичного популярного ресурса, нужно до этого популярного ресурса дорасти .Вас с Вашим популизмом даже до "песочницы" допускать опасно...

Basil A. SidorovАлексей ВахтинСколько клиентов было?В конкретном тесте - 90~120. Отдельный компьютер с гигабитной сеткой.
Расклад загрузки серверной части (две отдельные JVM) - 70-90 процентов для сервера приложений и 1-3 процента для собственно прокси.
90+% загрузки сервера - за такое на продакшене нужно стреляться...
И, кстати, у Вас прокси разве не на JVM работает?
Большее количество подключений еще больше нагрузит сервер - а расти уже особо некуда... На системные нужды тоже некоторое количество ресурсов требуются.
В итоге получается, что уже сотня даже "тестовых" клиентов (пусть и с неизвестным характером данных, которые Вы использовали для обмена в тестах) - и сервер в ступоре...
Хороший пример "простого копирования данных", которое "совсем не ресурсоемкая задача"...
Basil A. SidorovДля начала у нас будет их немного, а если их количество вырастет до, скажем, тысячи?Понимаете, в чём дело ...
Те же apache httpd и apache tomcat "искаропки" расчитаны на двести одновременных подключений. После минимальных настроек что тот, что другой без проблем выдерживают до 500 одновременных подключений. У меня не было цели определить пределы возможностей JVM/IP-стека, поэтому на бОльших значениях я не тестировал - пятьсот с разумным запасом закрывает наши потребности.С Вашими потребностями разобрались...
Терзают смутные сомнения (могу ошибаться) относительно взаимодействия apache httpd или apache tomcat с .NET...
Basil A. SidorovПо этим и некоторым другим тестам я могу сделать вывод, что на вполне типовом железа система "центральный сервер - клиенты за NAT/proxy" упрётся, скорее всего, в пропускную способность канала (вашего) сервера.Пока Вы продемонстрировали, что сервер приложений, а не канал узкая часть Вашей системы - слишком много ресурсов системы он отъедает под себя для выполнения сравнительно тривиальных задач.
Basil A. SidorovРезюме.
HTTP-протокол. Серверная часть на "классическом" CGI, сервлетах, модулях расширения конкретного сервера или даже на языках динамических страниц (PHP/JSP/ASP). Специализированный клиент или модуль расширения под конкретный браузер, реализующие логику вашей задачи.Для .NET - это, практически, прошлый век... С полным отказом от использования возможностей, предлагаемых средой.
Basil A. SidorovПрактически гарантированная "проходимость", понятные способы кэширования контента и масштабирования системы.Типа, в .NET ничего этого нет... Угу...

Basil A. SidorovДля .NET - это, практически, прошлый век... С полным отказом от использования возможностей, предлагаемых средой.Сначала определите, какой процент клиентов положит, в лучшем случае, болт на "возможности предлагаемые средой", а потом можно будет пообсуждать и альтернативы HTTP.Вообще-то предлагается альтернатива не столько одному из возможных транспортных протоколов (HTTP), сколько всему тому слабоструктурируемому "буллшиту", который предлагаете Вы и который тянется, в лучшем случае, с середины 1990-х гг.
Фреймворк Windows Communication Foundation, который является составной частью платформы .NET, заменяет его чуть более чем полностью.
И городить апачи, сервлеты, цги и прочий хлам при наличии весьма развитых возможностей WCF - мягко говоря, неразумно.

Basil A. Sidorovsphinx_mvФреймворк Windows Communication Foundation, который является составной частью платформы .NET, заменяет его чуть более чем полностью.Вы опять невнимательно читаете.
Во фразе "модуль расширения конкретного сервера" предполагалось (в том числе), что автор слабает "что-нибудь этакое под IIS на (своём любимом) це-шарпе".Это ничего, что для хостинга WCF-приложения никакой острой необходимости в IIS не наблюдается?

Модератор: Товарищ, смените тон.