Коллеги, всем доброго дня!
Есть такая проблема, с которой уже бьемся довольно продолжительное количество времени.
Суть: необходимо организовать стабильную и качественную систему передачи данных на сервер мониторинга.
Машины стоят внутри сети организации и шлют сообщения в формате протокола мониторинговой системы на уровне TCP, на каждое сообщение подобного рода с сервера должно прийти подтверждение о том, что оно получено, также в формате протокола мониторинговой системы. Если агент на клиентской машине не получает данного подтверждения, по истечению некоторого таймаута оно будет отослано снова, что может сформировать очередь на клиентской стороне. Сервер мониторинга стоит в совершенно другой сети и туда открыт только порт 443.

Что было сделано: все клиентские машины шлют свои сообщения на специальный концентратор, который "оборачивает" каждое сообщение в HTTPS и устанавливает сессию Request/Response, соответственно, на строне сервера мониторинга стоит приложение, которое "разворачивает" каждый пакет из сессии для дальнейшей обработки и "оборачивает" каждое сообщение-подтверждение со стороны сервера и отсылает его обратно. В сети организации также установлен прокси, собственно, который и перенаправляет все соединения на сервер.

Имеем проблему в производительности - то есть по факту у нас обрабатывается 4 сообщения в секунду, в результате получаем задержки в адекватном отображении информации о состоянии устройств клиентов.

Пробовали делать многопотосноть подобного решения, но судя по всему, прокси расценивает это как DOS-атаку и глушит все.
К сожалению, подробнее ничего не могу сказать о сети организации, так как она не предоставляет такие данные. Нам дали только выход на наш сервер мониторинга.

Дайте, по возможности, свои рекомендации и замечания.

P.S. Клиентские машины - WinXP + .NET, концентратор - Windows2008 + .NET, сервер мониторинга Win2008 + .NET

mad_nazgul,

Спасибо за подсказку, изучаю возможности

Petro123bender2002Если агент на клиентской машине не получает данного подтверждения, по истечению некоторого таймаута оно будет отослано снова, что может сформировать очередь на клиентской стороне.
тут подробнее.
- TCP гарантирует целостность передачи данных
- HTTP - нет, и к тому же медленный
Следовательно, чем не устраивает TCP, откуда берутся очереди и размер этих очередей.
Т.е. всегда ли доступен сервер чтобы НЕ делать очереди?

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

Petro123bender2002Если агент на клиентской машине не получает данного подтверждения, по истечению некоторого таймаута оно будет отослано снова, что может сформировать очередь на клиентской стороне.
тут подробнее.
- TCP гарантирует целостность передачи данных
- HTTP - нет, и к тому же медленный
Следовательно, чем не устраивает TCP, откуда берутся очереди и размер этих очередей.
Т.е. всегда ли доступен сервер чтобы НЕ делать очереди?

Не ответил на все вопросы:
1. TCP не устраивает тем, что принимающая часть реализована в составе ISAPI-фильтра, получается, что если переделывать все в TCP, то надо будет озадачиваться еще и изменением системы-приемника. К тому же, изменение политик на стороне прокси внутри организации процедура не самая простая в плане бюрократии

2. Сервер всегда доступен, то есть мы видим, как сообщения с концентратора отправляются и принимаются подтверждения, но получается, что пропускная способность ее очень невысока. А со стороны клиентской машины это все выглядит, как банальный таймаут по коннекту.

Petro123,

Я пообщался со своими коллегами в Бельгии (у них реализовано подобное решение), разница состоит в том, что у них установлен HTTP Load Balancer и он распределяет потоки с клиентских машин на 5 разных инстанций концентратора, установленных на одной машине. У них подобных проблем с пропускной способностью нет. Я пытался рассмотреть подобное, но не нашел готовых реализаций Load Balancer под винду, только по *nix, собственно там в Бельгии они так и поставили

Petro123bender2002,
ну понятно, либо переделывать всё по новой, либо добавлять машины - масштабировать))).
А никсы не так сложны в понимании и админстве как кажется "Оконнику")).

Всё таки замерьте маршрут и время прохождения...выложите тут.

Не боимся никсов-проблема только в бюрократии: не так просто установить что-то в организации не такая простая процедура, честно говоря, быстрее что-то написать

По поводу времени прохождения - в понедельник постараюсь выложить

Спасибо

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

В общем, пауза между запросом и ответом может составлять до 3-х секунд

Собственно, это и есть, считай, лог программиста.
То есть замерили фактическое время отправки сообщения на уровне приложения-концентратора и приема им ответа

Petro123bender2002Собственно, это и есть, считай, лог программиста.
То есть замерили фактическое время отправки сообщения на уровне приложения-концентратора и приема им ответа
тогда я лично не пойму, на что уходит 3 сек? Пауза на перекуры?
Пишу IMHO.

После того, как концентратор отправляет реквест, он идет сначала на прокси, затем по сети организации выходит на сервер мониторига (что там находится фактически, я, к сожалению, даже узнать не могу) после получения реквеста сервером мониторинга запускается процедура генерации подтверждения на сообщение, которое по такому же маршруту возвращается на концентратор.

3 секунды - это максимум. Есть отрезки, когда проход по всему маршруту занимает менее 1 секунды

К сожалению, нет.
Мне пояснили, что ICMP протокол закрыт на устройствах, потому единственным способом оценки времени маршрута является приложение.