Real-Time общение

HomoNumbius
Дата: 26.04.2010 16:31:04
Есть клиентское приложение на делфи, которое работает с базой данных через HTTP+IIS+веб-служба на .NET (грубо, короче делфи клиент общается с сайтом).

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

Вопрос подскажите как это реализовать, ключевое слово для поиска хотя бы :).
Про механизм работы аськи почитал в википедии )))) написано крайне поверхностно :(
Пробовал искать типа "как работает icq" тоже все поверхностно.
То есть мне нужен аналогичный протокол с возможностью прирутить его на свой сервер.
Какие есть варианты?
зы
Дата: 26.04.2010 16:50:24
comet
HomoNumbius
Дата: 26.04.2010 17:08:51
зы, спасибо, отличная идея, то есть сама концепция.
Жаль инфы очень мало как-то, но кое-что нашел почитать. Если что, вернусь :)
HomoNumbius
Дата: 26.04.2010 17:36:48
Почитал как народ сам пытается реализовать Comet в ASP.NET - думал уже готовое есть.
Суть действий сводится, насколько понял, к тому, чтобы замораживать на сервере запросы клиентов, пока у сервера на них нет ответа.
Для меня остался вопрос как тогда быть с отпадтом запроса по таймауту, хотя таймаут штука решаемая наверно :) или может есть http-запросы без таймаута? :)
Ну и наверно встанет вопрос насчет ситуации:
1. клиент отвалился от сети
2. в это время сервер был готов и кинул ему ответ
3. ответ не долетел
4. клиент, снова подключился, сообщение пропало...
что делать на этапе №3, чтобы сообщени долетело - но это наверно в каждом случае отдельно надо смотреть
зы
Дата: 26.04.2010 18:25:21
Таймаут в основном случается у клиента. Альтернативная реализация - long poll.
TCP/IP - протокол с подтверждением о доставке. Если сообщение не доставлено, отправляющая сторона об этом узнает и соответствующим образом сделает у себя пометку на повторную отправку.
Платная оптимизированная реализация под IIS - http://ajaxian.com/archives/websync-comet-for-iis
iConst
Дата: 27.04.2010 11:16:07
В одном из проектов была попытка приметить эту заманчивую технологию.
Проблемы возникли в том самом растянутом респонсе.
Он имеет свойство кумулятивного накопления. И если мы выводим информацию последовательно - типа строки чата, то все относительно просто.
Хуже дела с замещением информации в различных объектах DOM. Пришлось вводить маркеры гранулярных посылок.
На клиенте нет механизма отслеживающего приход очередной "посылки". Приходится периодически "трясти" контейнер с респонсом. И если его тряхнуть во время прихода данных, то появляются замороки с их целостностью. Все это, скорее всего, было преодолимо, но вело к чрезмерным временнЫм затратам.

В итоге мы отказались от этой технологии в пользу AJAX и клиентских таймингов.
Гуесто
Дата: 27.04.2010 12:00:13
HomoNumbius, а что на сокетах не судьба сделать? :)
HomoNumbius
Дата: 27.04.2010 17:35:04
Задумался... На сокетах возможно и правда проще и быстрее работать будет (минус IIS и .NET из цепочки). Какие могут быть камни пока не знаю, не юзал сокеты.
зы
Дата: 28.04.2010 16:56:33
Все то же самое, но процесс низкоуровнеого общения придется реализовать самому. В чем кайф?
ShSerge
Дата: 28.04.2010 17:05:39
Чё-то не въехал. Об аспнет речь? Или о чём? Если сокеты - при чём здесь сервер и при чём здесь браузер?
ПС. А болталки по UDP (типа аськи) достаточно просто пишутся. Только это никаким боком не аспнет.