Рекомендуемая реализация для настольного клиента веб-мониторинга?[закрыто]

Question

Фон

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

Требования к кандидатам

Версия 1:

Заявление должно:

• отслеживать использование Интернета на рабочем столе пользователя, отслеживая следующие области:

  • используемый браузер,
  • использовано часов
  • сайты, к которым был получен доступ
  • учитывает, какая вкладка браузера является «активной»

• Составьте отчет об этом использовании (в формате CSV или другой легко экспортируемый формат)

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

Для версии 2:

• уметь представлять графические результаты (круговые и гистограммы)
• быть мультиплатформенным (версия 1 предназначена только для Windows)
• Интегрируйте онлайн-компонент

Вопрос

Учитывая эти требования, какую техническую реализацию вы бы порекомендовали и какую платформу/языковую архитектуру вы бы порекомендовали?Ключевыми аспектами являются функциональность и, в широком смысле, низкое влияние на пользователей.Расчетное время прибытия или стоимость менее важны.

Answer 1

В прошлом году я построил нечто очень похожее на это.Я использовал С#.Первоначально он использовал часть платформы 3.5, но мне пришлось масштабировать его обратно до платформы 2.0 из-за ограничений по размеру установки.В настоящее время он контролирует около 13 000 машин.сбор и отправка обратно на сервер отчетов около 3 МБ данных в минуту.

Клиентские машины варьируются от процессоров Pentium 4 с 256 МБ ОЗУ под управлением XP до двухъядерных машин с 2 ГБ памяти.

Приложение, которое я создал, не должно было использоваться конечным пользователем, поэтому оно работает как комбинация службы Windows и подключаемого модуля вспомогательного объекта браузера для IE.BHO был необходим для того, чтобы точно зафиксировать, что происходит в браузере.

Единственная реальная проблема заключалась в том, чтобы заставить его работать под XP и Vista (все уровни пакетов обновлений), а также в IE 6 и 7.XP и Vista имеют разные последствия для безопасности, которые следует учитывать;IE 6 и 7 также имеют разные модели доступа.

Наконец, мы сделали ставку на Firefox или другие браузеры, потому что клиента это просто не волновало.

ОБНОВЛЯТЬ

Firefox поддерживает только JavaScript, C++ и xul для кодирования расширений;использование С# было бы полной PITA.Я бы, наверное, попробовал JavaScript, если бы он делал то, что мне нужно, просто потому, что это проще.

Что касается Chrome, то они только недавно начали поддерживать расширения (19 марта 2009 г.).Вам нужно изменить свойства запуска ярлыков, чтобы иметь возможность их запускать.Так что я бы, наверное, пропустил этот браузер, пока он немного не повзрослеет.Я предполагаю, что в следующем году будет много изменений в том, как создаются плагины для него.

Что касается объема данных в минуту, это совокупное значение.Каждый отдельный клиент регистрируется только раз в пятнадцать минут или около того;или при повторном подключении к сети при работе в отключенном состоянии.Таким образом, индивидуальный трафик довольно низок и не влияет на пользовательский опыт.

Брандмауэры

Причина, по которой брандмауэр для нас действительно не имеет значения, заключается в том, что данные передаются обратно на наш сервер отчетов через порт 80 с использованием веб-служб.Если 80 заблокировано, то они все равно не смогут просматривать, так что собирать нечего...Что касается пропускной способности, ограничьте то, что вы собираете и транслируете обратно.XML с длинными описательными именами атрибутов/значений НЕ ваш друг.

Answer 2

Похоже, что C# подойдет вашим потребностям, если он ограничен клиентом Windows.

Answer 3

Qt и C++ хороши для кроссплатформенных клиентов, особенно.если им нужно быть «экономными в отношении памяти» таким образом, чтобы не было решения на языке со сборкой мусора (т.е.в основном все остальные ;-) обычно есть.

Answer 4

Нам нужно больше информации:

Пришло ли время развивать проблему?С помощью C# вы можете быстро разработать такое приложение;но он не обязательно будет иметь такую ​​же низкую производительность, как C++.Вы можете разрабатывать определенные части на C++ (части, требующие интенсивного использования памяти), а другие — на C#, но тогда у ваших клиентов должна быть установлена ​​платформа .NET;не говоря уже о том, что они могли бы довольно легко перепроектировать части C#.

Существует треугольник проекта, и нам нужно знать, какие два из них наиболее важны для вас: