Архив форумов ЦИТФорума

[misnik]

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

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

Итак.

На форуме для отслеживания обновлений в темах и разделах я использую Cookie. Например, при открытии темы записывается следующий "кук": pbcforum_id_s_id_com, где s_id - это ID тему, а значение "кука" равно числу сообщений в теме в данный момент.
При открытии списка тем проверяется равенство "кука" числу сообщений в теме и на основе результата этого сравнения делается вывод о наличии новых сообщений. "Кук" ставится следующим JS-скриптом:

<script>
var to = 5*365*24*60*60*1000;
var expDate = new Date();
expDate.setTime(expDate.getTime() + to);

document.cookie = "pbcforum_id_s_id_com = $s_num; path=/; expires=" + expDate.toGMTString();
</script>\n";

Проверка осуществляется средствами PHP при генерации страницы.

Вроде, все правильно и должно работать.

Однако на практике часть "куков" умирает по непонятным причинам.

Выглядит это так. Захожу на форум, вижу 10 новых тем. Начинаю их просматривать, они становятся прочитанными. Вдруг открываю очередную тему, возвращаюсь к списоку, и вижу, что одна или две темы, которые 1 минуту назад были помечены как прочитанные, теперь отмечены, как имеющие новые сообщения. Начинаю разбираться, смотрю "куки" для данного домена - "кука" с данным ID просто нет (а 2 минуты назад - был, потому что я только что просматривал список и новых сообщений не было).

Можете сами проверить: http://rzforum.ru, откройте по порядку все темы, а потом рефрешните список тем.

И вот это происходит регулярно на всех браузерах (я смотрел в IE, Opera 7.51, Opera 8.01, Firefox). Хотя в теории вроде бы все правильно: "куки" записываются, имена "куков" не совпадают, expires установлены на 5 лет.

Но "куки" пропадают и это факт. А я не знаю, в чем дело: в браузере, который не хочет хранить два десятка "кук" для одного домена, в скриптах, в кривых руках или еще в чем-то.

[Anvano]

Ты прав, согласно RFC по протоколу HTTP

Количество поддерживаемых Cookie составляет не менее 20 штук. Но и больше делать никто не обязан.



RFC 2109, HTTP State Management Mechanism

[misnik]

Спасибо за ответ.

>> Так что придется тебе искать какой-нибудь другой механизм. Например хранить в Cookie только идентификатор сессии, а всё что с ней связано хранить где-нибудь в БД на стороне сессии.

Да, пожалуй.
Хотелось бы еще уточнить - вы упомянули БД как абстрактный ресурс или у вас есть основание полагать, что лучше использовать, скажем, mysql (или другую конкретную СУБД)?

Я спрашиваю, потому что с сессиями в таком виде раньше не работал, а сейчас в свете этой темы начал читать документацию по php-sessions и вроде это как раз то, что нужно - никакого дополнительного программинга и управления хранением и обработкой данных. Однако меня несколько пугает невозможность (трудность технической реализации) организации чистки такого хранилища, если с этим нельзя будет справится стандартными функциями, задающими время хранения кеша. (возможно, это чушь - просто я еще не начал пробовать, но перед этим хотел бы определиться с алгоритмом и тем, какие решения далее буду использовать)

[Anvano]

Я имею ввиду организацию хранения сессий в базе MySQL (PostgreSQL).
В большинстве форумных движков, например, именно так и реализовано.

Кстати реализация не так уж и сложна. В любой нормальной книжке по PHP можно найти целиком исходники класса по управлению сессиями через БД (точно видел в такой толстой красной книжке с кучей фотографий авторов на обложке и большими желтыми буквами PHP).

По поводу чистки. Идентификаторы сессий при обычном их использовании хранятся ввиде файлов на сервере в каталоге TEMP. Внутри этих файлов собственно и хранятся переменные сессий и их значения. Естественно чистку этих файлов никто не производит. Обычно для этого вешают скрипт на crontab, который раз в сутки чистит /temp

С точки зрения хранения в БД проблема чистки решается намного гибче. В той реализации класса по управлению сессиями, которую я упомянул есть механизм задания таймаута. А чистка производится в момент любого обращения к данному классу.
То есть пока на сайт никто не заходит - пусть всё в базе так и лежит, а как только произошло обращение к механизму управления сессиями, он делает delete из базы всех сессий, у которых вышел срок годности, и только потом продолжает работу.

[misnik]

А чем плох вариант с php-сессиями? На мой взгляд, он имеет одно важное преимущество - не привязан к БД, следовательно, должен работать быстрее (ведь файловые операции как правило оптимизированы и требуют меньше ресурсов, чем обращение к БД).

Я уже реализовал этот вариант. Вроде, все нормально. Можно задать время жизни сессии и кук, указать директорию для временных файлов и т.д. Таким образом, имеется та же функциональность как и при использовании БД и пришлось дописать всего 10 строк кода.
Сейчас тестирую.

[Anvano]

[misnik]

Я поспешил. Судя по всему, эти функции задают параметры кеширования страниц клиентом/прокси. Всего навсего.

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