Отправленные сервером события и php - что запускает события на сервере?

"..." stream.php "остается открытым, пока клиент" подключен "к нему?"

Да, и ваш псевдокод - разумный подход.

«А как узнать, можно ли ЗАКОНЧИТЬ экземпляр stream.php?»

В наиболее типичном случае это происходит, когда пользователь покидает ваш сайт. (Apache распознает закрытый сокет и уничтожает экземпляр PHP.) В основном вы можете закрыть сокет со стороны сервера, если вы знаете, что какое-то время не будет данных; последнее сообщение, которое вы отправляете клиенту, - это сказать ему вернуться в определенное время. Например. в случае потоковой передачи акций вы можете закрыть соединение в 20:00 и сказать клиентам, чтобы они вернулись через 8 часов (при условии, что NASDAQ открыт для котировок с 4:00 до 20:00). В пятницу вечером вы говорите им, чтобы они вернулись в понедельник утром. (У меня есть готовящаяся книга по SSE, и я посвящу этому вопросу пару разделов.)

"... если это так, PHP не подходит для такого типа серверов. Но все демонстрации, которые я видел до сих пор, подразумевают, что PHP подходит для этого, поэтому я так смущенный..."

Что ж, люди утверждают, что PHP не подходит для обычных веб-сайтов, и они правы: вы могли бы сделать это с гораздо меньшими циклами памяти и процессора, если бы вы заменили весь свой стек LAMP на C ++. Однако, несмотря на это, PHP поддерживает большинство сайтов. Это очень продуктивный язык для веб-работы благодаря сочетанию знакомого синтаксиса, подобного C, и большого количества библиотек, и удобен для менеджеров, так как множество программистов PHP, которых можно нанять, множество книг и других ресурсов, а также несколько больших варианты использования (например, Facebook и Википедия). По сути, это те же причины, по которым вы можете выбрать PHP в качестве технологии потоковой передачи.

Типичная установка не предполагает одно подключение к NASDAQ на каждый экземпляр PHP. Вместо этого у вас будет другой процесс с одним подключением к NASDAQ или, возможно, с одним подключением каждой машины в вашем кластере к NASDAQ. Затем цены переносятся либо на сервер SQL / NoSQL, либо в разделяемую память. Затем PHP просто опрашивает эту разделяемую память (или базу данных) и выталкивает данные. Или, у вас есть сервер сбора данных, и каждый экземпляр PHP открывает соединение сокета с этим сервером. Сервер сбора данных отправляет обновления каждому из своих клиентов PHP по мере их получения, а они, в свою очередь, отправляют эти данные своему клиенту.

Основная проблема масштабируемости при использовании Apache + PHP для потоковой передачи - это память для каждого процесса Apache. Когда вы достигнете предела памяти оборудования, примите бизнес-решение добавить еще одну машину в кластер или исключить Apache из цикла и написать выделенный HTTP-сервер. Последнее можно сделать на PHP, чтобы можно было повторно использовать все имеющиеся у вас знания и код, или вы можете переписать все приложение на другом языке. Чистый разработчик во мне напишет выделенный оптимизированный HTTP-сервер на C ++. Менеджер во мне добавил бы еще одну коробку.

События, отправленные сервером, предназначены для обновления в реальном времени со стороны сервера на сторону клиента. В первом примере соединение с сервером не сохраняется, и клиент пытается подключиться снова каждые 3 секунды, и события, отправленные сервером, не отличаются от опроса ajax.

Итак, чтобы соединение сохранялось, вам нужно обернуть свой код в цикл и постоянно проверять наличие обновлений.

PHP основан на потоках, и большее количество подключенных пользователей заставит сервер исчерпать ресурсы. Это можно решить, контролируя время выполнения скрипта и завершая скрипт, когда оно превышает заданное время (например, 10 минут). EventSource API автоматически подключится снова, поэтому задержка будет в приемлемом диапазоне.

Кроме того, ознакомьтесь с моей библиотекой PHP для событий, отправленных сервером, вы можете узнать больше о том, как выполнять отправленные сервером события в PHP и упростить кодирование.

Я заметил, что sse techink отправляет каждую пару данных о задержке клиенту (что-то вроде реверсирования пула данных techink со страницы клиента e.x. Ajax pooling data.), Поэтому, чтобы преодолеть эту проблему, я сделал это на странице sseServer.php:

<?php
        session_start();
        header('Content-Type: text/event-stream');
        header('Cache-Control: no-cache'); // recommended to prevent caching of event data
        require 'sse.php';
        if ($_POST['message'] != ""){
                $_SESSION['message'] = $_POST['message'];
                $_SESSION['serverTime'] = time();
        }
        sendMsg($_SESSION['serverTime'], $_SESSION['message'] );
?>

а sse.php:

<?php
function sendMsg($id, $msg) {
  echo "id: $id" . PHP_EOL;
  echo "data: $msg" . PHP_EOL;
  echo PHP_EOL;
  ob_flush();
  flush();
}
?>

Обратите внимание, что в sseSerer.php я запускаю сеанс и использую переменную сеанса! чтобы преодолеть проблему.

Также я вызываю sseServer.php через Ajax (отправка и установка значения variable message) каждый раз, когда я хочу «обновить» сообщение.

Теперь в jQuery (javascript) я делаю что-то вроде этого: 1) я объявляю глобальную переменную var timeStamp = 0; 2) я использую следующий алгоритм:

if(typeof(EventSource)!=="undefined"){
        var source=new EventSource("sseServer.php");
        source.onmessage=function(event)
        if ((timeStamp!=event.lastEventId) && (timeStamp!=0)){
                /* this is initialization */
                timeStamp=event.lastEventId;
                $.notify("Please refresh "+event.data, "info");
        } else {
                if (timeStamp==0){
                         timeStamp=event.lastEventId;
                }
        } /* fi */

} else {
        document.getElementById("result").innerHTML="Sorry, your browser does not support server-sent events...";
} /* fi */

В строке: $.notify("Please refresh "+event.data, "info"); вы можете обработать сообщение.

В моем случае я отправлял уведомление jQuery.

Вы можете использовать POSIX PIPES или таблицу БД вместо того, чтобы передавать «сообщение» через POST, поскольку sseServer.php выполняет что-то вроде «бесконечного цикла».

Моя проблема в то время заключается в том, что приведенный выше код НЕ ОТПРАВЛЯЕТ «сообщение» всем клиентам, а только паре (клиент, который вызвал sseServer.php, работает индивидуально для каждой пары), поэтому я изменю технику и на Обновление БД со страницы, на которой я хочу вызвать «сообщение», а затем sseServer.php вместо того, чтобы получить сообщение через POST, он получит его из таблицы БД.

Надеюсь, у меня есть помощь!

Это действительно структурный вопрос о вашем приложении. События в реальном времени - это то, о чем вы хотите думать с самого начала, чтобы вы могли проектировать свое приложение на основе этого. Если вы написали приложение, которое просто запускает кучу случайных mysql(i)_query методов с использованием строковых запросов и не передает их через какого-либо посредника, то во многих случаях у вас не будет выбора, кроме как либо переписать большую часть вашего приложения, либо делать постоянный опрос на стороне сервера.

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

<?php
class MyQueryManager {
    public function find($myObject, $objectId) {
        // Issue a select query against the database to get this object
    }

    public function save($myObject) {
        // Issue a query that saves the object to the database
        // Fire a new "save" event for the type of object passed to this method
    }

    public function delete($myObject) {
        // Fire a "delete" event for the type of object
    }
}

Когда вы будете готовы сохранить в своем приложении:

<?php
$someObject = $queryManager->find("MyObjectName", 1);
$someObject->setDateTimeUpdated(time());
$queryManager->save($someObject);

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

Вы, очевидно, не поймаете ручные изменения в базе данных таким образом, но если вы делаете что-либо вручную с вашей базой данных с любой частотой, вам следует либо:

• Устраните проблему, требующую внесения изменений вручную
• Создайте инструмент для ускорения процесса и запускайте эти события