написать простой аналог icq

[demav]

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

Будет база под MS SQL 2008 R2, где хранится список пользователей, история сообщений и др. логи.

Собственно вопрос вот в чем. Каким образом клиенту лучше получать сообщения?

1. Самый простой способ. Прямое подключение к базе (через ADO), клиент периодически опрашивает базу о наличии полученных сообщений. При отправке сообщения вызывается процедура в базе, сохраняющая сообщение в очереди.

Как мне кажется, минус в том, что будет сильно загружена база (и сервер).

2. Реализовать промежуточный сервер приложений, обрабатывающий запросы от клиентов.
На чем тогда его делать, с помощью Socket?
И будет ли выигрыш по загрузке базы -сомнительно.

3. Хотелось бы, чтобы клиент получал сообщения от сервера (push), а не опрашивал сервер периодически. Возможно ли такое или это получится доп. дыра к компу клиента?
Какая технология?

4. Как это реализовано в существующих решениях (icq, jabber и т.п.)?

 

[dustypup]

1. Угу, самый простой. В клиенте поток опроса сервера на предмет наличия новых сообщений. Простой запрос IF EXISTS... Тормозить не будет.
2. Выигрыша не будет. Промежуточному серверу все равно нужно лезть базу.
3. Помнится когда-то давно тоже сидел думал как бы пуш с сервера сделать. В итоге родился велосипед, который использовал системные хранимые процедуры сервера чтобы с их помощью подвешивать на таблицу с сообщениями трассировку и получать ответ если там произошли какие либо изменения. Вот примерно так: Для просмотра ссылки Войди или Зарегистрируйся
4. Вот тут есть исходники на дельфе: Для просмотра ссылки Войди или Зарегистрируйся

 

[demav]

2. Выигрыша не будет. Промежуточному серверу все равно нужно лезть базу.

При использовании промежуточного сервера все таки реализуется доп. безопасность, т.к. серверу SQL Server можно перекрыть доступ в интернет.
Т.е. в интернет обращаться будет промежуточный сервер (со своими возможными дырами, конечно).

 

[dustypup]

Стоит задача сделать внутрикорпоративный мессенгер

На то он и внутрикорпоративный чтобы в инет не смотрел. Если надо работать вне локальной сети, то vpn и вперед.

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

 

[sersin]

В Oracle использовал для этого Пул. Очередь прямое соединение.

 

[timedrops]

Я думаю, с такой нагрузкой справиться и mysql. Тем более внутрикорпоративный мессенджер. Сколько предполагаемых юзеров? Главное пользоваться хранимыми процедурами, и не делать жадных запросов типа select * from messages. Ограничивать дату выборки, например не доставлять клиенту сообщения старше 30 дней. Ещё сделать случайное время выборки - скажем 20сек+random(20). да, ещё не забываем про кеш. вот тут пара советов по оптимизации. Для просмотра ссылки Войди или Зарегистрируйся.
по мне первый вариант проще и надёжнее.

 

[VGA1212]

demav, ИМХО, проще всего клиентскому приложению слушать сокет, а из базы, например, из триггера посылать сообщение о том что для него что то есть. По крайней мере, в нашем проекте, мгновенные оповещения об изменении статуса задачи сделаны именно так.

 

[demav]

demav, ИМХО, проще всего клиентскому приложению слушать сокет, а из базы, например, из триггера посылать сообщение о том что для него что то есть. По крайней мере, в нашем проекте, мгновенные оповещения об изменении статуса задачи сделаны именно так.

Не понял куда чего посылает триггер, поясните плз. Триггер записывает в некую таблицу информацию о том, что для клиента что-то есть? Тогда все равно надо обратиться к базе, сокет не получится использовать.

Или если триггером посылает инфу через сокет (внешняя процедура, DLL), тогда клиентское приложение должно реализовать сокет-сервер, чтобы ему можно было отправить.
Короче, не понял

 

[VGA1212]

упрощенно выглядит так - на клиенте открыт на прослушивание tcp/ip сокет. В базе есть таблица в которой хранятся сообщения для клиента. Когда появляется новая запись срабатывает триггер, который определяет есть ли клиент в онлайн и с помощью расширенной хранимой процедуры отсылает пакет содержащий код сообщения на клиентский сокет. Далее клиент уже лезет в базу и достает тело сообщения.
В общем, как то так

 

[demav]

упрощенно выглядит так - на клиенте открыт на прослушивание tcp/ip сокет. В базе есть таблица в которой хранятся сообщения для клиента. Когда появляется новая запись срабатывает триггер, который определяет есть ли клиент в онлайн и с помощью расширенной хранимой процедуры отсылает пакет содержащий код сообщения на клиентский сокет. Далее клиент уже лезет в базу и достает тело сообщения.
В общем, как то так

Получается, что каждый клиент должен быть открыт "на вход". ОК, наверное, это можно принять.

Но также сервер должен хранить список текущих клиентов, постоянно им пробрасывать проверки на сокеты. Т.е. должен быть еще некий "сервер приложений" на сервере (вне сервера SQL).

Идея вполне реализуема, хотя и необычная.

 

[Freeon]

Вот вам пример многопоточки на indy
использовал данный код для создания некоторого подобия ftp с шифрованием на лету
система работает до сих пор
на краштесте выдерживала до 50000 подключений
ссыль.
Для просмотра ссылки Войди или Зарегистрируйся

 

[IPS]

Сокеты будет назначать сервер при подключении клиента (при прохождении иденфикации)

 

[azl]

Есть исходники R&Q, там все можно посмотреть. Для просмотра ссылки Войди или Зарегистрируйся

 

[fd00ch]

У либы RealThinClient есть демка с IM-клиентом, работа с сетью. Работу с БД напиши сам