Доброго времени суток!

Нахожусь в процессе написания утилиты, которая раз в несколько минут в отдельном потоке соединеняется с mysql сервером, выполняет запрос и отсоединяется от сервера (дескриптор соединения создаётся и уничтожается на стеке функции потока), т. е. «пересечений» между дескрипторами соединения с mysql нету.

Пишу под CentOS (2.6.18-53.el5), использую posix threads, собираю с -lmysql_client_r, mysql_thread_safe честно возвращает единицу.

Подключение проходит куда менее на ура, чем если делать в однопоточном режиме - хотя бы то, что блокирующий mysql_real_connect часто не срабатывает (т.е. возвращает NULL), при этом

mysql_error: Can't connect to MySQL server on 'xxx.xxx.xxx.xxx' (4)

mysql_errno: 2003 (CR_CONN_HOST_ERROR)

errno: 4

perror 4: OS error code 4: Interrupted system call

Это вроде объяснимо тем, что pthreads работает через сигналы, при этом не ставя SA_RESTART.

1) Поделитесь плиз, у кого есть соображения - почему mysql_real_connect иногда возвращает NULL, при этом:

mysql_error: Lost connection to MySQL server at 'reading authorization packet, system error: 0'

mysql_errno: 2013 (CR_SERVER_LOST)

errno: 0

- это все при том, что mysql сервер работает, не падает и при следующей попытке подключение успешно происходит?

Это лишь в дополнительных потоках, когда произвожу соединение из основного потока все идет четко и ничего не прерывается.

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

2) Вызовы mysql_options (с параметрами MYSQL_OPT_LOCAL_INFILE и MYSQL_OPT_CONNECT_TIMEOUT) могут длится несколько секунд (опять же в отличие от однопоточного режима) - за счет чего?

3) После успешной установки соединения делаю запрос load data local infile. Иногда mysql_query возвращает «nonzero», при этом

mysql_error: Lost connection to MySQL server during query mysql_errno: 2013 (CR_SERVER_LOST) errno: 0

Однако несмотря на возвращаемое значение, mysql_error,mysql_errno - запрос успешно выполнился! Но функция mysql_query возвращает признак ошибки. Собственно вопрос: на что можно сориентироваться в такой ситуации? В какую сторону нужно интерпретировать потерянное соединение в течении выполнения запроса? А то непонятно, как определять, прошел благополучно запрос или нет...

Приветствую!

Люди, подскажите кто знает плиз, есть ли возможность у tcp-сокетов (linux, не винда) в случае tcp-соединения отсылать данные «цельно»?

В случае датаграмного udp у меня таких проблем и вовсе не было - что recvrom что sendto всегда принимали/отправляли цельно.

А можно ли сделать такое в случае tcp-соединения? Как я понял в случае recv можно задать флаг MSG_WAITALL, а вот как быть в случае отправки? Есть ли возможность задания каких-либо флагов/опций сокетов, чтобы как в udp можно было «цельно» отправлять пакеты, размер мне заранее известен.

Заранее спасибо!

Доброго времени суток!

Конфигурация сервера, на котором работаю: Компилятор - gcc 4.1.2 ОС - Linux (rhel) 2.6.18-128.1.6.el5

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

функция gettimeofday возвращает время с поправкой на часовой пояс на сервере, в мануале, увы, не сказано, как получить время в utc. А ведь еще и летнее время существует...

Сам вопрос: есть ли какой-либо способ получить текущее время в utc, не анализируя файлы, в которых прописана временная зона сервера.

Заранее спасибо!

Доброго времени суток!

Не могу понять, как вычленять время из пакетов протокола Netflow версии 5.0.

Маршрутизатор Cisco 4507R, находится в новосибирске (GMT+6). Экспортирует flow-поток на одну из рабочих станций. Моя задача - вычленять оттуда некоторые пакеты, точнее данные с них. По-большому счету все понятно, кроме времени. Есть в протоколе следующие поля:

(Далее воспользовался информацией с http://www.securitylab.ru/forum/forum21/topic46779/messages/?PAGEN_1=2 )

/**********************************************************/

UNIX_SECS - Время когда поток был экспортирован - в секундах

SYSUPTIME - UpTime экспортирующей системы на время когда поток был экспортирован. Тут тысячные секунды

FIRST - UpTime экспортирующей системы на время когда поток был создан (получен первый пакет). Тут тысячные секунды

LAST - UpTime экспортирующей системы на время когда был получен последний пакет потока. Тут тысячные секунды.

Есть однозначная привязка UNIX_SECS и SYSUPTIME Поэтому формула для Unix_Time когда получен первый пакет потока такая.

Unix_Time_Flow_Created = UNIX_SECS + (FIRST - SYSUPTIME)/1000

Для последнего пакета потока - такая.

Unix_Time_Flow_Died = UNIX_SECS + (LAST - SYSUPTIME)/1000

Точность времени для данных порядка одной секунды, так как приходится округлять

/********************************************************/

Попробовал реализовать.

Что в итоге получаю:

Сегодня 05.05.09, местное время примерно 18.14. Время на экспортирующем маршрутизаторе указано верно.

Получаю пакет.

unix_secs (8-11) = 1241522062

sys_uptime (4-7) = 1228598392

first (24-27) = 1228430416

last (28-31) = 1228450356

Использую формулу, получаю

Unix_Time_Flow_Created = 1245816861

Для последнего пакета потока - такая.

Unix_Time_Flow_Died = 1245816881

преобразуем

select FROM_UNIXTIME(1241522062) as UNIXSECS,FROM_UNIXTIME(1245816861) as Unix_Time_Flow_Created

получаем результат:

UNIXSECS Unix_Time_Flow_Created '2009-05-05 18:14:22', '2009-06-24 11:14:21'

UnixSecs похож на правду, а вот Unix_Time_Flow_Created - ни в какие ворота - даже если прибавить шесть часов (GMT+6) то 24 июня 2009 тут совсем не при делах :(.

Подскажите в чем я не прав, кто знает, плиз.