stg-34

Учить матчасть, и только потом философствовать о потоках.

Именно.

Колонки: IP direction up down cash IP - адрес ресурса direction - еаправоение в которое попали up - исодящий траф (байты) down - входящи cash - сколько за это сняли денег Кажется так.

Мне пока нечего ответить, не успел изучить вопрос.

Ну, я собственно и предлагаю ввести в протокол доп. поля. Имхо, лучше пописать код, чем вставлять костылики. Благо расширить протокол и сохранить совместимость с существующим конфигуратором не есть проблема.

Господа, хочу вмешаться и высказать свое мнение. Во-первых, давайте как-то сдержанней себя вести, это относится ко всем, меньше неконструктивных высказываний Во-вторых, я хочу обрисовать свою позицию относительно внесения изменений в СТГ. Я не хочу вносить в СТГ "частные" случаи. Т.е. например, сделать конфигуратор, который для работы требует хранилище mysql и не нарботает с файловой базой или firebird. Как я это буду выкладывать на сайте? Что написать неподготовленным юзерам? Как параллельно поддерживать два конфигуратора и как в них фиксить ошибки, относящиеся к обоим конфигураторам одновременно? и т.д. и т.п. 2Max, если делать то, что ты предлагаешь, то, я думаю стоит пойти по пути универсальных решений. В чём сложность сделать еще десяток полей UsedRata, вынести в настройки сервера их названия, которые будут передаваться в конфигуратор или, даже, добавить новые поля в конфигурацию юзера? В таком раскладе, мы модернизируем три плагина для хранилищ, внесем изменения в конфигуратор и все будут довольны. В конце концов, если не хватает текстовых строк в конфигурации юзера сделать, что-то более навернутое. Далее, если нужно расширение данных в конфигураторе, то я категорически против того, чтоб часть данных шла через протокол конфигуратора, а часть - по другому пути, например прямые обращения к БД. Тоже самое касается авторизатора в режиме получения статистики. Я считаю, что правильным решением было-бы, создание плагина в категории plugins/other который бы работал практически как авторизатор, обеспечивал обмен данными, но не занимался самой авторизацией. Однако, этот вопрос тоже требует хороших усилий, т.к. общий код для этих двух плагинов нужно выносить в библиотеку. В-третьих, мне хотелось бы уйти от всех решений завязанных исключительно на виндах. Т.е. как минимум удалить авторизатор писанный на билдере (это уже сделано на 95% и может стоит автоидиагностику добавлять в него? я скоро прекращу поддержку авторизатора на билдере) и потом конфигуратор (тут конь не валялся), и наверное стоит озадачиться созданием кроссплатформенного конфигуратора или веб-конфигуратора (это тоже требует немалых усилий).

гламурно мне понравилось! будет ли автообнавление, без нажатие каждый раз на кнопку авто при запуске конфигуратора? все данные о пользователе будет хранится в базе? на счёт автообновления не думали... нада посоветоваться с програмистами все данные будут храниться в базе, изначально всё пишется под базу mysql В базе стг это будет?

А где можно исходники скачать? А, блин, пока нигде . Надо - зашлю. В принципе всё рабочее, надо тока под разные платформы раздуплить.

согласно гос контракта, тока мира, тоесть мы им и локаль должны считать как мир.... Шо-то ты гонишь... Смотри, если 30 гиг распределяются на мир и локаль, то тут спасает предоплаченный трафик плюс выставлять каждый месяц, например консольным конфигуратором нужные параметры. Иначе - юзать пороги, и возможно КК.

Автоматическое пополнение счета через вебмани? Не вопрос.

30 гиг мира или локали?

А что не работает и как ты собирал и инсталил?

А статистика через веб не спасет?

Статистики пока - да. Но будем делать подо всё.

Похоже победился баг с авторизатором. Качните, плз, еще раз архив Вчера просто какие-то чюдеса твороились Начиная с зависаний свитча, который никогда не вис, и заканчивая непакующимся архивом с исходниками. Но сегодня, похоже, всё пучком Проверили на debian 3.1, freebsd5, ubunta 6