HandyCache форум

Здравствуйте!

Такая просьба к разработчикам возникла.
Нельзя ли реализовать какой-нибудь интерфейс активности монитора, т.е. когда в мониторе появляется новая запись, HandyCache передает данную запись в некий интерфейс (например вызывает определенную процедуру из dll в качестве входящего параметров которой и будет запись монитора) а интерфейс (т.е. процедура dll) уже делает что хочет. Каждый сам сможет написать такую dll.
Это нужно например для складывания записей монитора в БД, и последующего анализа, и вообще создания биллинговой системы.

Если ты серьезно хочешь этим заняться, а не поиграться, обдумай что бы тебе хотелось и пиши, я готов к сотрудничеству.

Обязательно все это делать в реальном времени? Анализ логов Монитора не устроит?

В том то и суть, что хочетcя получать данные их монитора в реальном времени. Каждый раз перелапачивать лог монитора из текстового файла - это не совсем хорошо.
В общем в ближайщее время я попробую сформулировать идею более четко и представить ее на рассмотрение Автору HC.

В общем идея вкратце такая, она немного шире первоначальной мысли с dll.

Интерфейс взаимодействия обмена данными между HandyCache и сторонними приложениями.

Собственно идея состоит в следующем:

1.   Обеспечить передачу данных в сторонние приложения:
- в частности потоковая передача истории посещения ресурсов (т.е. активности монитора)
- передача результата выполнения команд полученных от сторонних приложений.

2.   Обеспечить прием команд из сторонних приложений, выполнение и подтверждение выполнения данных команд:
- Например стороннее приложение посылает команду «Заблокировать пользователя – Вася», HandyCache снимает «разрешение» для пользователя «Вася».

Технология обмена данными:

В качестве технологии обмена данными предлагается использовать технологию передачи данных на основе Socket (Сокетов).

Требования:

Необходимо разработать протокол взаимодействия обмена данными, т.е. перечень команд обрабатываемых HandyCache.

Пока хотелось бы получить следующее:

1.   Ввести настройку для передачи активности монитора (истории посещения) по сокету. И соответвенно описать протокол передачи. Лучше было бы если передача истории была сделана по сокету и была представлена в виде XML.
2.   Сделать пока пару команд:
- «Заблокировать пользователя – Вася», в результате которой пользователь будет заблокирован;
- «Разблокировать пользователя – Вася», в результате которой пользователь вася будет разблокирован.

В целом если предусмотреть такой интерфейс обмена данными и зарегламентировать протокол обмена, то сторонние разработчики будут создавать и административные консоли и билинговые системы, в результате задачей HandyCache останется именная та на которую он и задумывался а именно кэширующий прокси-сервер, в арсенале своем имеющий только перечень пользователей и разнообразные правила.
К сожалению я не могу его назвать локальным, иначе зачем был введен перечень пользователей. Многие используют HandyCache для организации доступа пользователей к сети интернет из локальной сети через одно соединение с интернет, т.е. проще говоря использую HandyCache именно как КЭШИРУЮЩИЙ ПРОКСИ СЕРВЕР - и эту задачу он выполняет отлично. Зачем на него вещать какие-то вещи, которые ему не присущи, например тот же биллинг. Хотят пользователи получить биллинг или административную консоль, пожалуйста пускай делают сами или сделает добрый человек и выпустит продукт на использование армии пользователей. Но чтобы это сделать, нужен зарегламентированный интерфейс и протокол обмена данными. HandyCache в свою очередь тогда бы развивался именно в направлении - КЭШИРУЮЩЕГО ПРОКСИ СЕРВЕРА и не более того. Зачем туда пихать биллинг, файрвол и т.п. подобные вещи, которые должны делать другие продукты, специально для этого созданные.
Ограничения по трафику, квоты и т.п., расчет по все возможным тарифам – в общем биллинг должны делать другие продукты, поэтому и необходимо предусмотреть интерфейс который бы мог помочь взаимодействовать с HandyCache другим приложениям.
---
Например, билинговая система знает:
- сколько пользователю выделено на потребление трафика (квота)
- на основе какой тарифной сетке рассчитывается трафик
- и т.п. данные.

Соответственно когда пользователь превышает допустимую квоту потребления трафика, биллинговая система должна сообщить HandyCache о блокировании пользователя, который в свою очередь должен это сделать и дать ответ биллинговой системе о результате выполнения команды.
Чтобы биллинговая система работала своевременно и четко, необходимо постоянная свежая статистика по потреблению трафика пользователем, вот для этого в принципе и нужна передача в реальном времени истории посещения, тогда данные всегда будут актуальны на данный момент времени и биллинговая система сможет на их основе принимать решения и давать команды на определенные действия HandyCache'у.

Neutral
Пока только общие слова. Ты конкретно что-то хочешь, можешь сделать или у тебя чисто теоретический интерес?

Интересен не теоретический!
Хочу сделать небольшую биллинговую систему, которая будет контролировать превышение пользователей по выданной ему квоте, и вести расчет стоимости согласно установленной тарифной сетке.
Думаю моя идея понятна, я готов начать разрабатывать биллинговую систему как отдельное приложение, которое будет взаимодействовать с HandyCache. Прежде всего это нужно мне, т.к. вопрос расчета стоимости полученного трафика пользователями передо мной сейчас стоит остро. HandyCache меня устраивает полностью именно как кэширующий прокси сервер. Очень нравится как в нем организован кэш, и работает достаточно быстро и четко.
Я с удовольствием поделюсь своей работой с другими пользователями HandyCache. Все что нужно для старта это дать начало реализации идеи со стороны HandyCache.

Хорошо, коли так.
Т.е. ты сделаешь сервер и НС будет слать ему информацию? ОК, придумывай протокол обмена.
Кроме активности монитора твой сервер еще список пользователей, зарегистрированных в НС, должен как-то узнать.
Если твое приложение будет сервером, то инициатива обменабудет за НС. Так ведь? Или ты как-то по другому представляешь?

Будет двухсторонний обмен.
HC постоянно будет слать в потоке на сокет каждую новую запись монитора (сейчас это сделано пока только настройкой "Сохранять содержимое монитора" которая сохраняет эти записи в файл). В дальнейшем нужно будет сделать, чтобы HC просто дублировать ее в сокет на определенный IP и порт. (формат передачи будет позже). По этому же каналу HC будет принимать и отсылать ответы на заданные ему команды.
Попробую подготовить протокол в ближайщее будущее и вышлю.

Кстати мой e-mail есть в моём профиле на форуме, вот на его бы выслали свое мыло, чтобы было куда слать инфу. Не в форуме же все время общаться.

Понятно, двухсторонний, но инициатива же только от клиента. Пока клиент не захочет что-то передать и команды никакой от сервера не будет.
Мое мыло: под конвертиком в моих сообщениях (ищи слева на уровне этой строки), на вкладке О программе в НС.

Может все-таки не сокеты, а вызов библиотечной функции? Т.е. НС загружает библиотеку и вызывает оттуда функцию ExchangeData (url_string, options) например и передает в параметре оптионс нужные данные, как-то имя пользователя, и т.д. а на выходе - код операции - разрешить, запретить и т.д.
А то с сокетами грустно это будет по скорости (если речь о tcp сокетах, как я понял).

создать биллинговую систему на основе данных монитора не получиться. о многом монитор умалчивает. снятые с него данные не отразят реальную картину расходования трафика.

Протокол Syslog (http://ru.wikipedia.org/wiki/Syslog)