Перейти до

Оптимальный способ получения данных о пользователе


Рекомендованные сообщения

...

Поверьте - проще и еффективнее единоразово осознать что не нужно трогать нормально работающий stargazer руками, после чего не иметь никаких проблем вообще.

Это на тебя так повлияла работа с первыми версиями старика :)

Если что-то не запрещено явно, значит это разрешено. Изменять параметры абона в процессе выполнения скриптов не запрещено - значит будем бороться с проблемами которые это вызывает.

Ссылка на сообщение
Поделиться на других сайтах

...

 

Вопрос к Madf: приемущества от смены порядка запуска модулей помоему очевидны - мы получаем возможность использовать gconf get

Раз вы не видите смысла значит есть и минусы - какие ?

Как минимум минус в изменении поведения по умолчанию. Вдруг для кого-то это окажется неприятным сюрпризом?

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

Хотя и здесь есть одна заковыка. Большинство плагинов при получении конфигурационной информации как раз и выполняют свою активацию... Но это уже чисто техническая проблема.

Ссылка на сообщение
Поделиться на других сайтах

Nightfly, помоему это ваши слова:

все ноги растут из изначально нежиспособной архитектуры

и затем:

Старгейзер руками не трогаем - религия такая.

Нее ну против религии я конечно ничего не имею.

Извините не знал.

...проблема записи сквозь него не актуальна, в данном контексте.

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

У людей ведь фантазия богатая, мало ли какой контекст у них будет.

А для себя благодаря Madf и Вам я все проблемы уже решил. За что ещё раз огромное спасибо.

Ссылка на сообщение
Поделиться на других сайтах
Как минимум минус в изменении поведения по умолчанию. Вдруг для кого-то это окажется неприятным сюрпризом?

Основная проблема текущей дефолтной очерёдности помоему как раз в сюрпризах. Изначально кажется что всё хорошо работает.

Ну никак я не мог подумать что если на тестовом сервере 3 юзера работали то уже с 7 будут проблемы. И когда я решился на установку старгейзера на реальный сервер с реальным числом юзеров и уже проверенными на том тестовом сервере скриптами, вот это был сюрприз на всю ночь я долго вообще не мог понять в чём дело. Думаю многие кто шёл по моему пути на этом месте отказались от старгейзера. Но вы безусловно правы, аналогичный сюрприз для провайдера с нескольками тысячами юзеров уже работающих на старгейзере будет несравнимо более катастрофическим, чем для тех кто только ставит.

Я кажется начинаю понимать Вашу религию :)

Ссылка на сообщение
Поделиться на других сайтах
Как минимум минус в изменении поведения по умолчанию. Вдруг для кого-то это окажется неприятным сюрпризом?

...

Я кажется начинаю понимать Вашу религию :)

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

Ссылка на сообщение
Поделиться на других сайтах

В прочем, в ваших словах есть рациональное зерно. Такое изменение порядка загрузки плагинов не должно отразиться на работе, и при этом оно вполне логично. Пожалуй, в 2.408 я пересмотрю порядок загрузки плагинов.

Ссылка на сообщение
Поделиться на других сайтах
Нее ну против религии я конечно ничего не имею.

Свечку бы еще поставить...

 

Если серьезно - старгейзер офигенен. И модуль мускуля который почему-то все время не любит madf тоже работает. Просто задача старгейзера это распределенные авторизация/аккаунтинг с которой он просто офигительно справляется. Если его не пинать по поводу и без.

 

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

Ну че, если очень хорошо подумать, то фишка прямого коннекта к мускулю из вынконфигуратора, была бы довольно востребованой среди страждущих. Допустим чтобы получать на лету для каждого юзера... эмммм.. да хоть цвет глаз из таблички `eyescolor`. В теории ровно три строчки для mysql_connect()/mysql_query()/mysql_disconnect(). Сам не написал по двум простым причинам: на Си у меня хорошо получаются только сегфолты (основная причина), конфигуратором никогда не пользовался (вторичная причина).

 

 

А для себя благодаря Madf и Вам я все проблемы уже решил. За что ещё раз огромное спасибо.

незачто, наша община сектантов продолжает молиться за вашу бессмертную душу.

 

madf

Если что-то не запрещено явно, значит это разрешено.

Ага, while (true==true) { sgconf set ..blabla... -u$user --ud1 $value } тоже типа не запрещено. Но кто сказал что так стоит делать и что это не закончится фигово?

Ссылка на сообщение
Поделиться на других сайтах

...

Если что-то не запрещено явно, значит это разрешено.

Ага, while (true==true) { sgconf set ..blabla... -u$user --ud1 $value } тоже типа не запрещено. Но кто сказал что так стоит делать и что это не закончится фигово?

А почему фигово? Вот у админа цель была - завесить Stargazer. Начальник ему денег не заплатил, например, вот он и устроил ему такую подлянку. Я не запрещаю устраивать подлянки с помощью Stargazer :)

Ссылка на сообщение
Поделиться на других сайтах
while (true==true) { sgconf set ..blabla... -u$user --ud1 $value }

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

Любой админ сразу поймёт почему скрипт виснет, ещё на стадии тестирования.

 

Вот этот способ (из документации) гораздо интереснее.

sgconf get -s <server> -p <port> -a <admin> -w <admin_password> -u <user> <options>

sgconf set -s <server> -p <port> -a <admin> -w <admin_password> -u <user> <options>

Ссылка на сообщение
Поделиться на других сайтах

Мне всё-таки удалось , благодаря помощи Madf, создать патч применение которго позволяет использовать в пусковых скриптах sgconf get и set при кол-ве юзеров always online более 60.

Может кому-то пригодится, а может когда-нибудь и в релиз попадёт :rolleyes: .

Патч добавляет новую функцию в плагин "always online autorizator", которая не даёт очереди скриптов переполниться или опустеть.

функция представляет собой управляемую, паузу которая активируется и деактивируется в зависимости от состояния очереди.

Функция содержит два важных параметра о значениях которых, хотелось-бы "услышать" мнение специалистов.

А так-же какие недостатки в целом есть у данного решения ?

Мне почему-то не удалось загрузить файл на форум, потому публикую патч так.

Для применения перед компиляцией поместить в каталог с исходниками и набрать в этой директории команду: patch -p1 < имя_файла_патча

Для отката patch -p1 -R < имя_файла_патча

 

Патч пока для версии 2.407-p1:

diff -u -r stg-2.407-p1/include/stg/settings.h stg-2.407-p1--/include/stg/settings.h
--- stg-2.407-p1/include/stg/settings.h 2011-05-19 19:03:26.000000000 +0400
+++ stg-2.407-p1--/include/stg/settings.h 2012-01-28 22:09:46.000000000 +0400
@@ -39,6 +39,7 @@
 virtual unsigned			GetMessageTimeout() const = 0;
 virtual const std::string & GetMonitorDir() const = 0;
 virtual bool				GetMonitoring() const = 0;
+	virtual int				 GetExecMsgKey() const = 0;
};
//-----------------------------------------------------------------------------

diff -u -r stg-2.407-p1/projects/stargazer/plugins/authorization/ao/ao.cpp stg-2.407-p1--/projects/stargazer/plugins/authorization/ao/ao.cpp
--- stg-2.407-p1/projects/stargazer/plugins/authorization/ao/ao.cpp 2011-05-19 19:03:27.000000000 +0400
+++ stg-2.407-p1--/projects/stargazer/plugins/authorization/ao/ao.cpp 2012-01-29 00:41:56.000000000 +0400
@@ -30,6 +30,8 @@
#include <algorithm> // for_each
#include <functional> // mem_fun_ref

+#include <sys/msg.h>
+#include "stg/settings.h"
#include "stg/user.h"
#include "stg/users.h"
#include "stg/user_property.h"
@@ -126,6 +128,7 @@
 Unauthorize(*users_iter);
 UnSetUserNotifiers(*users_iter);
 ++users_iter;
+	SleepWhileNotFreeQueue();
 }
isRunning = false;
return 0;
@@ -246,6 +249,7 @@
 USER_IPS ips = u->GetProperty().ips;
 if (ips.OnlyOneIP())
	 {
+ SleepWhileNotFreeQueue();
	 if (u->Authorize(ips[0].ip, 0xFFffFFff, this) == 0)
		 {
		 }
@@ -287,3 +291,19 @@
auth.UpdateUserAuthorization(user);
}
//-----------------------------------------------------------------------------
+void AUTH_AO::SleepWhileNotFreeQueue() const
+{
+//STG_LOGGER & WriteServLog = GetStgLogger();  // для отладки
+int msgID = msgget(stgSettings->GetExecMsgKey(), 0); //получаем идентификатор очереди
+struct msqid_ds data;
+struct timespec ts = {0, 4000000};//0.004 сек  //значение паузы между запросами состояния очереди во время ожидания её освобождения
+msgctl(msgID, IPC_STAT, &data);	//запрос состояния очереди для определения необходимости ожидания её освобождения
+//WriteServLog("Msg in queue: %d", data.msg_qnum); // для отладки, позволяет увидеть в логе процесс заполнения очереди
+
+while (data.msg_qnum > 1)	//цикл ожидания освобождения очереди до заданного значения заполненности
+ {
+ nanosleep(&ts, NULL);	//пауза между запросами состояния очереди
+ msgctl(msgID, IPC_STAT, &data);   //запрос состояния очереди
+ }
+}
+//-----------------------------------------------------------------------------
diff -u -r stg-2.407-p1/projects/stargazer/plugins/authorization/ao/ao.h stg-2.407-p1--/projects/stargazer/plugins/authorization/ao/ao.h
--- stg-2.407-p1/projects/stargazer/plugins/authorization/ao/ao.h 2011-05-19 19:03:27.000000000 +0400
+++ stg-2.407-p1--/projects/stargazer/plugins/authorization/ao/ao.h 2012-01-28 22:07:59.000000000 +0400
@@ -77,7 +77,7 @@
 void				SetAdmins(ADMINS *) {}
 void				SetTraffcounter(TRAFFCOUNTER *) {}
 void				SetStore(STORE *) {}
-	void				SetStgSettings(const SETTINGS *) {}
+	void				SetStgSettings(const SETTINGS * s) { stgSettings = s; }

 int				 Start();
 int				 Stop();
@@ -105,6 +105,8 @@

 mutable std::string errorStr;
 USERS *			 users;
+	const SETTINGS * stgSettings;
+	void				SleepWhileNotFreeQueue() const;
 std::list<USER_PTR> usersList;
 bool				isRunning;
 MODULE_SETTINGS	 settings;
diff -u -r stg-2.407-p1/projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp stg-2.407-p1--/projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp
--- stg-2.407-p1/projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp 2011-05-19 19:03:27.000000000 +0400
+++ stg-2.407-p1--/projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp 2012-01-28 21:26:57.000000000 +0400
@@ -240,12 +240,12 @@
//-----------------------------------------------------------------------------
uint16_t STG_CONFIG::GetStartPosition() const
{
-return 220;
+return 10;
}
//-----------------------------------------------------------------------------
uint16_t STG_CONFIG::GetStopPosition() const
{
-return 220;
+return 10;
}
//-----------------------------------------------------------------------------

Ссылка на сообщение
Поделиться на других сайтах

Интересная особенность патча, не смотря на значение параметра равного 1

while (data.msg_qnum > 1)	  //цикл ожидания освобождения очереди до заданного значения заполненности

последовательность пуска скриптов выглядит так:

3 скрипта OnConnect

соответствующие 3-ём OnConnect скрипты OnChange

3 следующих OnConnect

соответствующие 3-ём следующим OnConnect скрипты OnChange

.....

.....

На самом деле так и должно быть, первый скрипт OnConnect сразу забирается из очереди на выполнение, второй заполняет очередь до 1 и только третий заполняет очередь до 2 что по условию активирует приостановку заполнения очереди из плагина "ао". После чего в очередь встают и выполняются скрипты OnChange.

Когда в очереди стоит последний не выполнненый OnChange, приостановка заполнения очереди из плагина "ао" деактивируется и в очередь снова попадают скрипты OnConnect.

Ссылка на сообщение
Поделиться на других сайтах

Вопрос про параметры, я так понимаю, касается задержки и длины очереди?

Правильных цифр тут быть не может.

В 2.408 патч точно не войдет, и в том виде в котором он представлен он вряд ли вообще попадает в кодовую базу. Пока буду искать более правильное решение проблемы.

Ссылка на сообщение
Поделиться на других сайтах
Вопрос про параметры, я так понимаю, касается задержки и длины очереди?

Да.

Правильных цифр тут быть не может.

А с текущими цифрами возможны какие-то грабли ?

 

 

Мне казалось я всё предусмотрел.

Из моих соображений как недостаток можно рассматривать большое число опросов состояния очереди на медленно выполняемых скриптах,

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

Ссылка на сообщение
Поделиться на других сайтах

Я увидел один серьёзный недостаток собственного решения,

Патч с текущими цифрами не позволит в полной мере использовать возможности "ExecutersNum" с большими значениями.

Хотя всё будет работать маленькая очередь станет слабым местом системы :)

Ну а с большими цифрами снова создастся опасность переполнения очереди.

А с текущими цифрами возможны какие-то грабли ?

вопрос снят.

Ссылка на сообщение
Поделиться на других сайтах
Вопрос про параметры, я так понимаю, касается задержки и длины очереди?

Да.

Правильных цифр тут быть не может.

А с текущими цифрами возможны какие-то грабли ?

 

 

Мне казалось я всё предусмотрел.

Из моих соображений как недостаток можно рассматривать большое число опросов состояния очереди на медленно выполняемых скриптах,

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

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

Максимальный размер очереди слишком мал - неэффективно используется очередь (простои в работе системы). Максимальный размер очереди слишком велик - вероятность блокировки при переполнении.

Даже 1 может быть слишком много - в скрипте можно изменить тысячу параметров и получить дедлок.

Тут нужно искать другое решение проблемы.

Ссылка на сообщение
Поделиться на других сайтах

Я увидел один серьёзный недостаток собственного решения,

Патч с текущими цифрами не позволит в полной мере использовать возможности "ExecutersNum" с большими значениями.

Хотя всё будет работать маленькая очередь станет слабым местом системы :)

Ну а с большими цифрами снова создастся опасность переполнения очереди.

А с текущими цифрами возможны какие-то грабли ?

вопрос снят.

К стати, увеличение ExecutersNum должно было помочь в вашем случае без внедрения этого "ручного управления доступом".

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...