Вообще, имхо, проблема надумана. Это задача клиента - запрашивать список накиданых ему файлов. Если он не ждет этой инфы, то и не поймает файлов (спрашивается, каким макаром предполагается впихивать ему эти данные). А если ждет - пусть сам и запросит.

Dimitry SibiryakovА догадаться, что именно сейчас имеет смысл запрашивать он должен как?..

А как "догадываются" все мейлеры, агрегаторы rss и прочего? Да, регулярно теребят сервер. И это нормально.
Можно сделать и событием, только придется еще предусматривать возможность того, что оно не будет принято, и генерировать его повторно при следующем коннекте.

Кстати, любопытно узнать, каким образом организована доставка сообщений.

Dimitry Sibiryakov,

что ни говори, а принцип "коннект - запросить - получить - дисконнект" по сравнению с "коннект - держать коннект - слушать, вдруг сервер что-то скажет - получить, если сказал - снова слушать" намного более проста, надежна и обкатана годами.

Но опять же, интересно узнать, как реализована доставка сообщений. На основе этого механизма сделать отправку файлов не так уж сложно, кмк

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

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

miwaonline,
ну да. Значит, все верно сделал :). А насчет обрывов - даже если внезапно разорвать соединение на клиенте, на сервере все равно возникнет событие дисконнекта. Если же предусмотреть случай отключения сервера (при этом таблица онлайна не очистится), то надо делать дополнительные проверки. У меня похожая задача, я добавил в таблицу текущих подключений время коннекта и время последней активности (в моем случае таблица исключительно для целей мониторинга, поэтому актуальность данных в ней не критична; соответственно отдельных процедур чистки "мертвых" юзеров я делать не стал). соответственно "мертвые" юзеры определяются на глаз. Можно завести отдельную задачу планировщика, которая будет выполнять отстрел "неотчитавшихся" юзеров раз в пару минут (потребуется сторонний софт планировщика + скрипт + isql).
Вообще для таких случаев идеально подошла бы in-memory таблица, но, к сожалению, в ФБ такой нет.

miwaonlineА каким образом в этой таблице появится информация, которой еще нет в ТРС/ІР стеке ОС?
Я про то, чтобы таблица очищалась при рестарте сервера, а ты о чем?