vovksextra

Поправленный выложили? А то 1.88.9 уже и найти не могу, а тарифы в download не становятся... sgconfig.1.90.9.win.exe Можно ли узнать кой какую деталь..... Я так понимаю исходников "компонент" относящихся к старгейзеру более не будет? Проект переходит плавно в проект с закрытым кодом?

Если 1С не работает под MS SQL + Terminal, то сначала сделай именно так, а уж потом примешь решение нужен тебе винт или нет )) На nowa.cc найдешь все ответы на свои вопросы

У мну именно cap_bpf Дайте линк пожалуйста где мона прочитать как прикрутить какой нииь другой модуль для подсчета трафика плизз Этот модуль просто ставится по дефолту Stg v. Stg 2.404 Вообщем я тыкнул пальцем разрабочкам как можно заставить считать правильно траффик через BPF. Это остается на их совести )) Для не верующих фом могу выслать бинарник под ФРЮ 6.3 - пусть сами поссмотрят . На подходе новый биллинг (готовность 90%) . Осталось совсем малость - слепить конфигуратор.

Рейтинг ПО повышают не сертификаты, а положительные отзывы тех кто этим ПО пользуется ))

Нужен сертификат на биллинг? Или лицензия на вид деятельности? )) Это совсем разные вещи. И как можно получить сертификат на систему с открытым исходным кодом - ума не приложу ? где смена одно байтика кода тупым юзером может повлечь за собой кучу судовых исков и т.д. т.п. в адрес разработчика ))) Вообщем бред это все.

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

забери еще раз из шапки архив (добавил исходники) недостающие "юниты" найдешь здесь: http://local.com.ua/forum/index.php?showtopic=10236&st=0 (в шапке найдешь ссылку на исходники на компоненту версии 2.0.1.6) подправишь dpr и все это дело соберешь на Delphi 7

вот собственно в этом-то и проблема, что НЕТ!!! я тоже решил перейти с фс на бд исходная версия 2.2.2 2006 года и при попытке доступа выдает сообщение о не правильном заголовке. Такое же сообщение выдает новый конфигуратор, когда я им попытался подключится к старой версии СТГ. Можно попросить исходный код или сделать еще одну сборку со старой библиотекой? К сожалению ничем не могу помочь, т.к. разбираться со старым протоколом - физически нет времени

Учить матчасть, и только потом философствовать о потоках. Учитесь прислушиваться )) У меня с мат частью все нормально. Я на потоки убил очень много времении и в своем приложении сделал так как все нужно, как книжка пишет. а вам еще раз следует прочитать Обработчики сигналов и маски сигналов Обработчики сигналов относятся к уровню процесса. Для ожидания сигналов настоятельно рекомендуется применять функцию sigwait. Функцию sigaction применять не рекомендуется, так как список обработчиков сигналов хранится на уровне процесса, и любая нить процесса может изменять его. Если две нити указали один и тот же сигнал в обработчике сигналов, то вторая нить, вызвавшая функцию sigaction, переопределит параметры, заданные первой нитью; предсказать порядок, в котором будут выполняться нити, в общем случае невозможно. Маски сигналов обслуживаются на уровне нитей. У каждой нити может быть свой набор сигналов, доставку которых она заблокирует. Для работы с маской сигналов вызывающей нити следует применять функцию sigthreadmask. Функцию sigprocmask не следует применять в программах с несколькими нитями - это может привести к непредсказуемым результатам. Функция pthread_sigmask во многом схожа с функцией sigprocmask. Параметры и способы применения обеих функций одинаковы. При преобразовании существующей программы в версию с поддержкой библиотеки нитей функцию sigprocmask можно заменить на pthread_sigmask.

И всеж пересмотрите работу с потоками., а именно обработчик сигналов. PS BPF подправили?

Он и не работает - когда делаешь kill процессу. Кто сказал что он работает? В файлах нули, в фиреберде мусор. Еще раз повторюсь ОС FreeBSD 6.3 Если бы писали как рекомендует RSDN - я бы тему не поднимал

to madf, stg34 СОВЕТУЮ ПРОЧЕСТЬ http://publib.boulder.ibm.com/infocenter/s...cNode=int_14825 Обработчики сигналов и маски сигналов Обработчики сигналов относятся к уровню процесса. Для ожидания сигналов настоятельно рекомендуется применять функцию sigwait. Функцию sigaction применять не рекомендуется, так как список обработчиков сигналов хранится на уровне процесса, и любая нить процесса может изменять его. Если две нити указали один и тот же сигнал в обработчике сигналов, то вторая нить, вызвавшая функцию sigaction, переопределит параметры, заданные первой нитью; предсказать порядок, в котором будут выполняться нити, в общем случае невозможно. Маски сигналов обслуживаются на уровне нитей. У каждой нити может быть свой набор сигналов, доставку которых она заблокирует. Для работы с маской сигналов вызывающей нити следует применять функцию sigthreadmask. Функцию sigprocmask не следует применять в программах с несколькими нитями - это может привести к непредсказуемым результатам. Функция pthread_sigmask во многом схожа с функцией sigprocmask. Параметры и способы применения обеих функций одинаковы. При преобразовании существующей программы в версию с поддержкой библиотеки нитей функцию sigprocmask можно заменить на pthread_sigmask.

Упертость хороша вещь ))) 6 лет ведь уже баги ловим можно здесь, например, прочитать http://www.rsdn.ru/Forum/message/2890085.flat.aspx

А, ну все понятно. fpc - FreePascal? То у тебя паскаль так с нитями дружит. PS: проверил тот-же пример на FreeBSD 5.3-RELEASE с теми-же результатами что значит так дружит с нитями? Вызываются все-равно ведь API функции и процедуры ))) (если ты не знаешь то могу сказать что FPC это не интерпретатор а компилятор ) Если функция или процедура не описана ее можно запросто подключить, например так function fpsigwait(__set:psigset_t; __sig:plongint):longint;cdecl;external name 'sigwait'; external - говорит что она внешняя и выше нужно описать какую либу подключить. вот и все. А древние стереотипы о качестве той или иной среде разработке тебе не мешало-бы давно стереть ))) Ибо один х..й - только вид сбоку. Мне просто не понятно где в коде СТЖ используются методы pthread_sigmask и тому подобные вещи !!!!!!!!!!!!!! Как вообще код СТЖ попадает в перехватчик сигналов ????? У меня при такой реализации код вообще не выходил из главного цикла при SIGINT например......А тупо прерывался где хотел. Ибо не понятно какя именно нить получит сигнал. Или что то я не понимаю..... А что касается того что я говорил: Для неотделенного (PTHREAD_CREATE_JOINABLE) потока очень важно, чтобы после того, как он завершится, к нему присоединился другой поток, - иначе ресурсы этого потока не будут освобождены для использования новыми потоками. Это обычно приводит к утечке памяти. Если не требуется создавать поток, который будет присоединен, нужно создавать его ОТДЕЛЬНЫМ. вообщем спорить здесь нечего - у меня все завелось и работает в отличие от СТЖ а разработчику советую поссмотреть в сторону sigwait и в сторону отключаемых потоков и еще поссмотри здесь. Думаю здесь самое правильно решение http://damao.net/vhosts/node.to/sigtest.tgz а то что завелся одиночный поток - это еще не показатель.

Пишу под FreeBSD 6.3 , компилятор fpc 2.2.0, использую libphtread. Поставь с портов FPC - я для тебя сделаю код (похожий как у СТЖ) - откомпилишь и глянешь сам . А затем сделаю как нужно и еще раз глянешь. Иначе нет смысла вести диалог.

Просто не хотел готовить список параметров в виде ppchar для вызова exec-ов. В паскале нужно брать бубен в руки для такого рода операций. )) А что касается глюков fork и POSIX Threads - может все дело не в "старых ядрах", а в не умелом использовании нитей. ;-) Я когда создал нить (делал точно так как в старгейезере) откопилировал под фрю она вообще не "заводилась" без pthread_join, а когда ее подключил, то обработчик сигналов не реагировал ни в какую на нее. Это было до тех пор пока я не сделал отключаемую нить и не переделал main loop (это единственная нить подключаемая во всем приложении) в предыдущем посте я выложил пример. Я вообще перестал после всего того что я перепробывал - понимать как вообще работает код старгейзера.......Но это так мысли в слух. А насчет буфера bpf увеличь его и проблема потери пакетов будет решена ))) Также очень долго не мог понять зачем в модуле Inetaccess нужна интересная процедура DummySend. Когда в своем коде наткнулся на этот эффект начал понимать ))) Сначала ее повторил, но как-то все не красиво получилось. Перешел на poll и не нужно было ждать 2,5 секунды что-б она вызвалась (разработчик поймет о чем идет речь) А также я увидел очень много вещей мне не понятных и не поддающихся логике . Вообщем пора начинать писать stargazer 3.0 (желательно с нуля) иначе тупик. Не сегодня так завтра. Вообщем сама идея такого рода биллинга с таким функционалом 5+++ и аналогов нет - но очень хромает реализация. Думаю что за 6 лет можно было и порядок навести. Думаю что критика будет воспринята адекватно. PS Когда перешли на новый релиз + фиреберд - думали что проблема с пропаданием данных решится - но не так-то было. 1. Когда завели админа и перегрузили сервер - то в поле пароль стали крякозяблы. 2. Залипают пользователи (это проблема уже поднималась - грешили на "фазы") 3. Самое интересное - по непонятным причинам - примерно в 20-00 каждый день - старгейзер (новый) переставал считать трафик (юзера ходили на шару). Как следствие каждый день в 19-45 перегружали сервер, заводили админов и т.д. В итоге перешли на старый релиз (временно - пока свой не заведем) проблема пустых файлов решается постоянным "таром" проблема Broken pipe - решилась закомментированием записи в лог Вот такие вот дела ....

Но ведь будет лучше если ты прочитаешь по "максимуму" и "быстренько" распарсишь. А пока будешь парсить - буфер не успеет переполниться. И что касается буфера - увелить его и увидишь положительные отзывы )) а иначе зачем нужен этот код при 128 байтах )) Он теряет весь свой смысл. if(bd->r > bd->sum) { memcpy(buffer, (char*)(bd->p) + bd->bh->bh_hdrlen, blen); //strncpy(iface, settings->iface[n], 9); //*iface = settings->iface[n]; bd->sum += BPF_WORDALIGN(bd->bh->bh_hdrlen + bd->bh->bh_caplen); bd->p = bd->p + BPF_WORDALIGN(bd->bh->bh_hdrlen + bd->bh->bh_caplen); bd->bh = (struct bpf_hdr*)bd->p; } Если у тебя стоит фря могу скинуть бинарник + авторизатор - поссмотришь как живенько все считает на 100Мбит - загрузка проца 0.1%. Если поставишь fpc - могу дать наработки, которые уже есть. И еще уж очень сильно накрутили с выполнением скриптов. Я взял код выполнения скриптов у Netams - немного переделал (Заменил execl на popen и pclose ) получилось просто и сердито. function ExecuteScript(FNameScript: string; FParams: string): cint; var pid: cint; ign, intact, quitact: SigactionRec; newsigblock, oldsigblock: tsigset; f: textfile; s: string; begin result := 0; if fpaccess(FNameScript, X_OK) <> 0 then begin result := -1; exit; end; ign.sa_handler := SigActionHandler(SIG_IGN); fpsigemptyset(ign.sa_mask); ign.sa_flags := 0; fpsigaction(SIGINT, @ign, @intact); fpsigaction(SIGQUIT, @ign, @quitact); fpsigemptyset(newsigblock); fpsigaddset(newsigblock, SIGCHLD); fpsigprocmask(SIG_BLOCK, newsigblock, oldsigblock); pid := fpFork; case pid of -1: result := -1; 0: begin fpsigaction(SIGINT, @intact, nil); fpsigaction(SIGQUIT, @quitact, nil); fpsigprocmask(SIG_SETMASK, @oldsigblock, nil); s := FNameScript + ' ' + FParams; popen(f, s, 'r'); if fpgeterrno = 0 then pclose(f); fpExit(127); end; end; fpsigaction(SIGINT, @intact, nil); fpsigaction(SIGQUIT, @quitact, nil); fpsigprocmask(SIG_SETMASK, @oldsigblock, nil); end;

Пока не начала писать под ФРЮ я тоже так думал.Просто фря более щепетильна ко всякому роду багов, которых ее наделали программисты. А теперь по делу. Недавно недельки (три назад) мы начали писать биллинг на (FPC). Написали модуль перехвата пакетов через BPF и через IPFW. Для ускорения работы взяли за основу исходники старгейзера. Когда настал тот миг когда мы смогли посчитать траффик выяснилось: 1. через BPF к нам не попадает очень большая часть пакетов. А если выставить скорость 100 Мб/с. то пакетов приходит всего 5%. 2. Через Диверт - вообще ничего не принимал. Далее начался процесс поиска инфы со всех источников. 1. Диверт побороли сразу. Что сделали 1. Приняли пакет 2. Если длина принятых данных больше чем размер IP хидера+ICMP хидера - пустили на прасер 3. Отдали его в таком состоянии как и приняли (Sendto). В Старгейзере немного другой алгоритм. Он просто ест ICMP пакеты и не только.... 2. Что касается BPF Полазив по докам выяснили что ФРЯ может выделить командой BIOCSBLEN буфер длиной аж 525Кб (Старгейзер выделяет всего лишь 128 байт, разработчик пытался получать только заголовки - вот и попался) И пока он обрабатывает очередной пакет в ядре идет просто переполнение буфера приема и ядро съедает все пакеты которые стоят в очереди. Полечилось очень просто выставили буфер в 1Мб вызвали Ioctl + BIOCSBLEN , прочитали тот размер буфера который нам был выделен и все. Правда пришлось переделать сам алгоритм приема. вот переделанный алгоритм function DoRun(p: pointer): pointer; cdecl; var ubpf: TPacketSniffer; begin ubpf := TPacketSniffer(p); ubpf.isRunning := True; log('Entering BPF thread'); while not ubpf.isStoped do begin ubpf.RecvPacket; end; ubpf.isRunning := False; log('Exiting BPF thread'); DoRun := nil; pthread_exit(nil); end; procedure TPacketSniffer.RecvPacket; var R: PRecInterface; BPF_HDR: PBPF_HDR; pbuff: PChar; packet: TPacket; i: integer; res: integer; begin for i := 0 to FListInterfaces.Count - 1 do begin R := PRecInterface(FListInterfaces.Items[i]); if R^.isOpen then begin fppoll(@R^.FPoll, 1, 1); if (R^.FPoll.revents and POLLIN) = 1 then begin R^.FPoll.revents := 0; res := fpRead(R^.fd, buff, BUFF_LEN); if res > 0 then begin pbuff := buff; while pbuff < buff + res do begin BPF_HDR := PBPF_HDR(pbuff); if GetIPPacket(pbuff + BPF_HDR^.bh_hdrlen, packet) then begin Inc(R^.Count); packet.intf := 1 shl i; packet.date := BPF_HDR^.bh_tstamp; if Assigned(FOnPacket) then FOnPacket(packet); end; pbuff := pbuff + BPF_WORDALIGN(BPF_HDR^.bh_caplen + BPF_HDR^.bh_hdrlen); end; end; end; end; end; end; Уже при буфере в 256 к на скорости 100Мбит - не теряется ни один пакет ))) На эксперементальном сервере стоит проц. дурон 1.6 и ОЗУ 512.И даже poll не помеха. Руководствовался вот этим: http://osdir.com/ml/network.tcpdump.devel/...0/msg00043.html Although we didn't implement the get/set bufsize functions for other platforms, I did some research and found the following: DEF = default buffer size DEFMAX = max buffer size without kernel tuning MAX = inherent limit for kernel buffering * bpf BIOCSBLEN FreeBSD DEF = 4-32K depending DEFMAX = 512K-1M MAX = 16M(?) AIX ??? И вот этим http://canmore.annwfn.net/freebsd/bpf.html Сам алгортим разбора пакетов брал здесь: http://packetstormsecurity.org/sniffers/gdd13.c Так что если разрабочики подкоректируют алгоритм подсчета трафика через BPF - то "трудоемкий" диверт просто будет не нужен. А что касается потери данных на ФРЕ при попытке закрыть приложение - это отдельная тема. Есть две проблемы: 1. первая - перехват сигналов. (Это отдельная тема) 2. что мне удалось словить - это закрытие потоков , а именно таймаута в 5 секунд - обычно мало что-бы выйти из цикла и произвести все процедуры записи. Ежели 5 секунд истекло а поток все еще работает вызывается тривиальный pthread_kill(ххххх, SIGINT). 3. Да и вообще организована не правильная работа с потоками. Линкс кушает а вот ФРЯ ....... Например вырезка из кода int USERS::Start() { if (ReadUsers()) { WriteServLog("USERS: Error: Cannot read users!"); return -1; } nonstop = true; if (pthread_create(&thread, NULL, Run, this)) { WriteServLog("USERS: Error: Cannot start thread!"); return -1; } return 0; } Обратим внимание на pthread_create(&thread, NULL, Run, this) в качестве атрибутов - передано NULL Значит у нас будет создана подключаемая нить (THREAD_CREATE_JOINABLE) Если была создана подключаемая нить, для нее необходимо вызвать функцию pthread_join. В противном случае в системе может оказаться недостаточно памяти для создания новой нити, так как каждая нить занимает относительно большой объем. Более подробная информация о функции pthread_join . Источник: http://publib.boulder.ibm.com/infocenter/s...n_variables.htm Нужно грамотно делать так пример на fpc pthread_attr_init(@attr); pthread_attr_setdetachstate(@attr, PTHREAD_CREATE_DETACHED); res := pthread_create(@ThreadBPF, @attr, @DoRun, Self); pthread_attr_destroy(@attr); и т.д. но тогда перестают работать такие вещи как sigaction(SIGTERM, &newsa, &oldsa); (на фре это точно, не знаю как на линкусе) Тему поднимал здесь: http://forum.vingrad.ru/forum/topic-206058.html ответов не дали. пришлось переделывать MainLoop Вырезка из кода. procedure MainLoop; var sigmask: sigset_t; threadID: pthread_t; begin fpSigfillset(sigmask); fpSigdelset(sigmask, SIGKILL); fpSigdelset(sigmask, SIGSTOP); fpSigdelset(sigmask, SIGCONT); pthread_sigmask(SIG_BLOCK, @sigmask, nil); pthread_create(@threadID, nil, @DoRun, nil); log('Signal main thread started for: SIGHUP, SIGTERM, or SIGINT (shell ctrl-c)'); pthread_join(threadID, nil); end; Вот здесь очень удачное решение !!!!!! http://damao.net/vhosts/node.to/sigtest.tgz вообщем ловить баги при такой реализации - дело очень плохое. Вот и дергнуло нас написать свой биллинг с авторизатором. Много вопросов возникло с самой авторизацией, а именно "всякие там" фазы. Уж больно все сложно - Из-за этих фаз и началось все. Поставили новый релиз - перешли на Фиреберд и тут на тебе - клиенты начали "залипать". Переписали свой алгоритм - до боли простой Клиент раз в 5 секунд передает пакет Ping - сервер отвечает Pong (вместе с инфой))). И на сервере крутится поток который ищет всех абонентов от которых он некоторый период не получал Ping и отключает от сессии. Все довольно просто - зачем нужно все так усложнять.

Я с PHP не дружу, но дружит приятель )). с Си на Pascal - перевел Покажи то что ты реализовал уже (как передавал логин). Может вместе с ним и что-то родим.

Оно то так. Только я не правильно сформулировал задачу. Эта утилитка позволяет заграбить данные из одной базы и слить в другую - нужно, например, для перехода с одного хранилища на другое. Если у кого есть желание покодить могу выделить исходники.

Делали такое - не помогло

странное дело версия 401 и 402 отлично находят библиотеки в /usr/local/lib/ вроде уже поддерживается, в http://stargazer.dp.ua/download/server/2.4...g-2.404.9.7.src собирается с мусклом если находит библиотеку mysqlclient Это всего лишь условная поддержка.То-есть не гарантированная.

Вообщем переходили с FileStore на FireBirdStore и возник вопрос переноса данных. Набросали маленькую утилитку, которая забирает инфу у одного сервера и позволяет эту инфу выгрузить в другой сервер (или в тот же). Наводить "лоск" времени не-было. Так что кому сойдет - пусть пользуются. PS. Утилита только забирает инфу у пользователей и все. Для переноса - вам нужно забить тарифные планы. Достаточно только наименования. Наименование тарифного плана в новом сервере должно совпадать один к одному как у старого. Вообщем пробуем (у нас все получилось) Удачи)) http://www.komservice.net/uploads/files/Backup.zip Забыл сказать что это утилита Storage - не зависима

спасибо друг, все заработало . Будешь в наших краях - с нас пиво ))

user.cpp: In member function `void USER::Connect(bool)': user.cpp:611: error: 'class USER_PROPERTY<std::string>' has no member named 'c_str' gmake: *** [user.o] Ошибка 1 никуя )) Товарищи Сишники - предлагайте решение. А то я смотрю в коду и ничего не вижу))