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

Вариант первый.
Клиент - AJAX, который посылает через AJAX каждые n секунд запрос на сервер, мол не изменилось ли чего там?
Сервер - пхп/перл.. не столь важно.. обработать такую информацию не затратит много усилий, если ставить разумное значение n.

Вариант второй.
Клиент - Флеш (или тот же активх/аякс, если такое там возможно)
Сервер - демон, написанный на си/перле, который постоянно включен.
Клиент с сервером создаёт постоянное TCP-IP соединение по определённому порту..
Не знаю возможно ли такое вообще, но вроде я где-то такое читал и даже примеры видел..

Ну вот пока что пара самых нормальных вариантов.. Варианты с фреймом и почими извратами прошу не обсуждать..
Хотелось бы так же знать как реализуется большинство чатов на аяксе.. как первый вариант?

ЗЫ: Прошу модераторов/админов извинить, если я создал не в том подфоруме.. ИМХО, этот подфорум больше всего подходит.. Если нет - переместите..

Думаю, что да - как первый.

Второй вариант лучше. Ход мыслей правильный. Подробностей я не знаю, но реализовывать нужно с помощью flash socets (широковещательная рассылка). А за подробностями обращайтесь в соответствующий подфорум.

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

Добавлено через 4 минуты и 45 секунд
вот кстати тема про сокеты.. там даже примеры есть.. (хотя прямое соединение с пхп - это изврат, конечно.. даже представить такое сложно %) )
http://forum.vingrad.ru/forum/topic-51094/...cket/index.html

А что мешает написать все это с Ajax'ом? imho, на флеше чат делать - разве что ради красивостей и удобностей флешовых, а не заради пущей оперативности доставки сообщений... Для повышения оперативности можно поменять логику опроса "новых сообщений". К примеру, пусть в нормальном состоянии все клиенты чата опрашивают сервер раз в 30 секунд. Если юзер начинает набивать ответ - на сервер уходит сигнал "набивает...", и все, кто успел опросить сервер за время от этого сигнала до реальной посылки начинают опрашивать сервер чаще, к примеру, раз в 10 секунд... Реактивность системы несколько повышается...

а вот я посоветую использовать java аплет.

А еще можно совмещать различные технологии - кто где лучше работает.

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

Поддерживаю. Я это и имел в виду.

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

Да. Это ограничение присутствует. Более того есть особенности при обращении к javascript из flash в разных броузерах на разных платформах (сталкивался).
Есть компромис:
сделать оба варианта. Если флеш есть - работает флешевая рассылка, если нет - AJAX.

Подходит? 

бээ.. сильно муторно.. ну по крайней мере для меня. Тобишь то, для чего я это собираюсь делать того не стоит 
Ещё бы хотелось узнать про серверную часть.. Кто что прелагает?..

А вообще может у кого-нить есть примеры в действии? Только не предлагать к просмотру чат на аяксе или чат на флеше.. может быть есть совмещённое, о чём мы с вами сейчас говорим..? :о)



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

Мнэээ.... А о чем это мы говорим ?  Совмещенное с чем?
насколько я понял - тут звучали два принципиально разных, не пересекающихся почти ни в чем подхода. Метод опроса и метод установки прямого соединения. Для первого случая ничего проще ajax+PHP, к примеру, или, там, Perl, придумать сложно. Для второго предполагается разрешения у клиента на запуск флеш или Java-апплетов. Так как только они имеют возможность устанавливать это самое соединение. На серверной стороне должно быть что-то посложнее PHP. Конечно, можно и на нем написать TCP демона, но лучше - не надо... К примеру та-же Java, для пущей переносимости... 

непрерывный коннект

ну не знаю, собственно...
я как раз сейчас делаю на ajax:
посылаем запрос серверу, где указываем последний id скачанного сообщения. сервер обращается к БД, выбирая из таблички новые сообщения, кидает их в JSON обратно. на клиенте распарсиваем по получении и вставляем куда надо. сразу же делаем новый запрос. я лично даже никаких задержек не использую..

Добавлено через 10 секунд
могу показать, кому интересно

Alx, А в локалке чат на 100 человек промоделировать пытался? Не всякая машина в таком случае "долетит" . Разумнее, imho, задержки все-таки использовать, но ставить их по началу посылки запроса новых сообщений. В случае, если предыдущий запрос не закончился - ставим флажок, если закончился - перезапрашиваем. Ну и по завершении запроса по флажку - перезапускаем запрос... Так будет сложнее завалить сервер в моем примере ;)

ksnk, так я вызваю новый запрос только когда получаю данные от предыдущего.. то есть точно знаю, что он уже выполнился..

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

я думаю стоит всё-таки делать задержки. причём можно сделать условия: если в чате мало народу - задержки будут маленькие.. если увеличиваются, то и задержки тоже будут расти. Задержки будет расчитывать сервер и передавать каждому клиенту.. Таким образом мы не допустим чтоб сервак загнулся.. И это думаю разумное решние, даже если чат будет тормозить...
Ещё можно подумать насчёт "пользователь набирает сообщение".. о чём писал ksnk, но имхо это будет только лишь создавать лишние запросы.. другое дело если бы набирались длинные сообщения.. а то сильно малое время проходит от начала набора сообщения до его отправки...


ну распарсивать там сильно не надо.. просто XML тупо используем и всё..


чё-то я не понял что ты хотел сказать.. т.е. ты, чтобы получить данные делаешь ещё один запрос? а не проще все данные отправить в предыдущем? :/ Зачем?!

affka, я получаю JSON-массив с сообщениями в виде JSON-объектов, содержащих в себе время сообщения, ник, id, и собстенно текст. а на клиенте уже средствами JavaScript генерирую HTML, распределяю сообщения по адресатам (если это приват) и форматирую их.

нет. отправил запрос - ..ждём.. - получил результат - (можно сделать задержку) - отправил запрос - ..ждем.. - получил рузультат,.. и т.д.