madf

Это проверено? По поводу WSACleanup? Я так мыслю, что когда соединение ствится в очередь на listen на стороне инициатора происходит блокировка нити до того момента пока не установится соединение. Потом на клиентской стороне соединение успешно выполняется.

всё известно, только не заполнено в БД. Это ты мне как разработчику говориш? Могу привести выдержки из кода Рекомендую посмотреть parser.cpp конфигуратора Или просто лог работы сервера при добавлении пользователя в конфигураторе: сперва происходит добавление пользователя а сразу за ним - сохранение его параметров. После добавления в базе хранятся фейковые значения параметров.

Если не используется ipq или divert. Тут могут быть неправильные правила файрвола.

Стоп-стоп! Конфигуратор работает по TCP и не держит сессию дольше чем необходимо для трансфера данных. Если в этот момент кто-то еще лезет с подключением - он попадает в очередь на listen до следующего accept. Откуда тут могут быть SIGPIPE? Хм. Посмотрел на плагин конфигуратора. rsconf.cpp: 126 res = listen(listenSocket, 0); Попробуйте 0 заменить, скажем, на 16. man listen: Но все равно не понятно откуда там SIGPIPE.

Сейчас в OnUserAdd кроме логина ничего не передается. Создание пользователя происходит в 2 этапа: собственно создание и сохранение параметров. В момент OnUserAdd кроме логина пользователя еще ничего неизвестно, по этому нету смысла передавать тариф или IP-адрес. Они попадут в OnChange, который будет выполнен следом.

Этот баг точно проявлялся при работе с firebird. В остальных случаях он был или очень редкий или совсем не проявлялся. Непосредственно с firebird он никак не связан, а связан с логирование работы сервера. Можете просто закоментировать код функции printfd в файле common.cpp библиотеки common.lib и пересобрать проект (если у вас stg с динамическими библиотеками - пересобрать библиотеку и положить ее вместо старой). Это должно помочь.

Почему нету? Сделайте так как написано выше.

Я бы посоветовал посмотреть tcpdump'ом что с ICMP от stg происходит. Конкретно интересуют source и destination ip.

Говорил мне -HS- что глючит пингер. Но как-то не верилось - других сигналов не поступало.

Это какие-такие поля звездочкой обозначены?

Я в VLAN не силен. Как на сервере они прописаны? Разные интерфейсы?

Если я правильно понимаю, VLAN'ы разделены на уровне свитчей. stg совершенно пофиг откуда пришел трафик - он его просто считает. Так что я думаю, наличие VLAN'ов никак не повлияет на работу stg.

В последних версиях (Новая сборка СТГ 2.4) этого уже не должно быть.

Вы не firebird, часом, в качестве БД используете? И еще: попробуйте эту версию и почитайте что писали тут Возможно, Ваши проблемы уже решены?

Абонка снимается за период работы пользователя. Т.е., например, если пользователь был "заморожен" пол месяца - у него снимется только половина абонки. Чтобы всегда снималась полная необходимо выставить в конфиге stg параметр FullFee=yes

Ну если ты предложиш способ быстрого вычисления позиции первого символа строки в файле и корректного adjust позиции первого символа следующей строки в этом-же файле при записи строки другого размера чем она была ранее - тогда да. Но, на сегодня, это займет намного больше временеи чем удаление файла и его перезапись. CONFIGFILE не знает о том какие данные должны быть в std::map и сколько. Да и не может знать - это универсальная читалка/писалка конфигов. Можно, конечно, добавить проверку на required fields или еще чего-нибуть, но при этом резко возрастут тормоза при записи. И сложность алгор

Encode12/Decode21 - это MIME-like кодирование. По этому ты не сможешь сделать Decode21 для произвольной строки. Собсно, эти две функции как раз и делают безопасным любой текст для вставки в XML. Сервер не должен завалиться ни при каких входных данных. Там же идет шифрование и проверка. Так что "левые" запросы будут отсеиваться еще на ранних стадиях. При ошибке сервер со своей стороны закроет соединение и авторизатор получит доступ к серверу.

C++ очень сильно отличается от Object Pascal.

1. При сохранении параметров нету смысла в проверке наличия bak-файла. Он нам нужен только при чтении. BAK_FILE создает дубликат файла с расширением .bak 2. Внимательно смотри конструктор класса CONFIGFILE. Файл открывается на чтение, зачитывается, сохраняется в std::map<std::string, std::string> и закрывается. При записи строки в файл она сперва обновляется в std::map а потом вызывается Flush. Flush все содержимое std::map сбрасывает в файл (файл при этом открывается и закрывается). Вот и все.

В последнем авторизаторе есть опция: его иконка в трее начинает мигать когда на счету остается меньше N денег. N - настраивается.

Да, если такое вбить в поле пароля сервер его не приймет. Парсер скажет что-то вроде "no element found". Но сервер при этом не падает. (Запишем'c: "добавить кодирование строковых полей" Если у тебя есть набор символов для какого-нибуть поля, которое вызывает падение сервера - скажи плиз.

".bak-файлы, .bak-файлы!" Они должны быть вне зависимости от того дописал сервер файл или нет. Если stg падает - он не удаляет их за собой.

Не подтверждается. Вбивал - все нормально работает.

2fernir: Подозреваю что патченный стг - старый стг (да это и по версии видно), который еще с x86_64 не дружил. А непатченный - новый, который уже дружит с x86_64 и в нем отсутствует семейство функций strto* (их заменяет одна шаблонная: str2x<typename>). Модуль mysql, лежащий на v-lan для этой версии не адаптирован. У нас уже есть адаптированная версия модуля, которая пойдет с релизом, но она пока нигде не выложена.

Есть такой момент. Фикс может быть быстрый и неправильный (костыль) или долгий (не ранее stg-2.5) но правильный. Городить костыли не хочется, а переколбашивать сейчас ядро системы - оттянуть и так затянувшыйся релиз. Если уж сильно горит - могу выложить патчик.