Ну да.. мультиплексинг. Да нет, у меня недоверие вызвает все попытки работать с низкоуровневыми функциями из высокоуровневого языка =) Хотя работает, да... Но у мультиплексинга есть свои недостатки... хотя, думаю, вы их знаете сами...
avm, угу.. и это не новость, имею опыт реализации такого чата лет 10 назад на перле =) Правда я использовал fork механизм. А он использовал мультиплексинг... тоже там свои тараканы. Только не понимаю, почему это отношение не имеет к HTTP? Разве протокол где-то устанавливает время выдачи контента? Не встречал... по сути, такой чат - это один длинный HTTP запрос, с заголовками и всем таким, чем надо - иначе браузер просто это не поймет. Мне не ясно, что вы подразумеваете под концепцией IRC? Многопотоковый сервер? Извините, но это транспортный уровень OSI и никакого отношения к прикладному уровню, будь то IRC или HTTP это не имеет. Или поддержание постоянного соединения? Или push доставку?
Вот именно - это и есть HTTP в соответствии с RFC. Но только не "один длинный запрос", а множество коротких в рамках одного непрерывного tcp-соединения. И что тогда автор имел ввиду под фразой "Это позволяет сократить ~95% HTTP запросов."
Davil, С помощью написания на ПХП собственного сервера, понимающего протокол HTTP 1/0, слушающего один или несколько выделенных портов. Ещё раз http://ru.php.net/sockets avm, Это не теоретические рассуждения, а вполне реально работающая схема, собственно я даже не против поделиться исходниками, но т.к. с моей точки зрения они представляют некую ценность (пока я не видел аналогичных реализаций), с моей стороны есть одно условие. Мне для тестирования чата нужен сайт с высокой посещаемостью, где спокойно можно собрать онлайн юзеров 500 (в чате), и конечно серверные ресурсы для испытаний. Это предложение ко всем кого, оно может заинтересовать. HTTP заголовки необходимы, т.к. браузеры у нас понимают только их, да и сами ими пользуются, хочеш не хочеш надо подстраиваться под существующие условия. Без изобретения своего протокола тоже не обошлось, для защищённого управления сервером формируется простенький заголовок, содержащий название протокола пароль и длину пакета данных, пакет данных представляет собой сериализованный массив с командами чат серверу. Помимо этого сервер имеет некоторую защиту от флуда на уровне поддерживаемых протоколов.
avm, И всё таки один длинный, заменяющий 95% коротких -) HTTP 1/0 не ограничивает ни длину ни время загрузки данных в течении одного соединения. Правда некоторые браузеры рвут соединение, если в течении нескольких часов небыло получено ни одного байта данных, но эта проблема решается элементарно.
ONK, ну вот и славно. Имхо, все встало на свои места (для меня во всяком случае). Кстати, вы используете такую технику как "В случае интенсивной нагрузки, сообщить клиенту явно более длинный Content-Length: и потом досылать данные до его исчерпания по мере повления новых сообщений"? Это действительно позволило бы сэкономить на отправке http-запросов к серверу...
440Hz, бот нужен нетривиальный, боюсь это достаточно сложная задача. Я пока ограничился тестированием сервера с помощью ab и ошибочных пакетов с данными.
Нет, множество коротких в одном соединении - это keep-alive. Тут он совсем не помошник. А в данном случае - это один длинный с дооолгим ответом =) Есть серьезные отличия от обычной мультиплекс схемы с использованием select или poll ? =)
Если мне память не изменяет, этот заголовок можно вообще не выставлять. Правда, во времена моих экспериментов какой-то из браузеров (нетскейп 4-й, что ли) очень глючил без контент-длины =) Пришлось в итоге и правда поставить какой-нибудь большой... мегов на 500 =)
В случае мультиплексирования - да. Смотрим информацию по неблокирующим операциям ввода-выода, select, poll и прочее. Но это одна из технологий. Другие - это порождение процессов (fork()) и использование нитей (threads). Более подробно о плюсах и минусах этих способов можно узнать в гугле =)
avm, HTTP 1/0 при ответе 200 OK не предусматривать заголовка Content-Length (хотя все современные браузеры его понимают). Браузер должен слушать порт до обрыва соединения со стороны сервера. Клиенты напрямую обращаются к серверу только для подключения к порту, с которого получают команды, далее клиенты отправляют свои запросы на дополнительные скрипты, реализующие бизнес логику чата, а они в свою очередь отправляют команды управления на сервер чата по защищённому протоколу.
Davil, это pcntl http://ru.php.net/manual/ru/function.pcntl-fork.php ну как же так? http://lg.adamant.net/web/rfc1945.html#sec-10.4 между броузером и сервером могут быть и прокси...
MiksIr, ценность в отсутствии аналогов на ПХП -), я начинал писать этот сервер когда sockets было ещё глубоко экспериментальным расширеним, думаю/уверен это был первый почти полноценный HTPP сервер написанный на ПХП. Я бы с удовольствием послушал про недостатки мультиплексирования. Я с ходу вижу тольк один (невозможность распараллелить процесс, если есть несколько процессоров), но это не является узким местом такого чата. Зато я вижу два огромных преймущества - это производительность и экономия оперативной памяти.
avm, значит я отложил у себя в голове совсем другую, нужную мне информацию. http://lg.adamant.net/web/rfc1945.html#sec-10.4 [qoute]Otherwise, the body length is determined by the closing of the connection by the server.[/quote] И что? Не вижу никаких проблем.
Вообще самая большая Ж в мультиплексировании, как я понял - это то, что один процесс может монополизировать сервер... но тут мне много до конца не ясно, так что не буду рассуждать. Второе, что подсказывает здравый смысл - любая долгая операция внутри сервера (например, задержки при работе с базой или еще что-то) приведет к тому, что "отдыхают все" =) По-этому код ядра должен быть вылизан в этом плане. Исходя из этого же... получил ты сообщение от своих скриптов... и должен распихать его клиентам... чем больше клиентов, тем больше времени тебе распихивать... в итоге, при большом количестве клиентов повышается... как бы это сказать... latency =)
MiksIr, По поводу первого пункта я не очень понял, процесс запускается от соответствующего пользователя, имеет соответствующий приоритет выполнения, непонимаю как он может монополизировать сервер/процессор. Отдыхают все клиенты, другие процессы при этом не страдают. Как раз для предотвращения подобных вещей я вести свести весь обмен данных напрямую, между скриптом и сервером методом подключения к сокету. Операции сервера с базой данных сводятся к уборке мусора при потере соединения с клиентом, и определении разрешено ли подключение с данного ip адреса. Опять же по моим оценкам сервер не является узким местом, и при условной 100%-й загрузке однопроцессорного сервера работой чата, на сервер чата придётся 1-2% процессорного времени. Ну от этого никуда не деться, и дело даже не в самом сервере и времени распихивания всех данных всем клиентам, а в том, что скорость передачи данных к клентам достаточно низка, и записать в сокет больше текущего размера буфера OC не получится. Это вызывает (потенциально может вызвать) значительно большие задержки чем сама работа серверного скрипта (десяток миллисекунд на 100 клиентов). Собственно я не вижу способа избежать этих задержек и при разветвлении процессов. Вообще форкать ПХП это тоже самое. что запускать каждому клиенту собственный сервер для удержания его коннекта, это слишком расточительно по ресурсам. avm, не могу сказать что мы познакомились, но поболтать было забавно. )