Сервери FastCGI, HTTP, CGI, FlashPolicy, Telnet, клієнти mysql, memcached, mongodb - ось неповний список функціоналу, реалізованого в цьому демона, створеному російським програмістом Василем Зоріна.
Втім, нас зараз цікавлять тільки WebSocket, і це phpDae-mon теж вміє. Процес установки фрейворка має свої нюанси, тому зупинимося на ньому трохи докладніше.
PhpDaemon вимагає для своєї роботи бібліотеку libevent - це кроссплатформенная бібліотека для асинхронної роботи з мережею, що надає механізм, який використовує функції зворотного виклику. У репозиторії Pecl є розширення для роботи з libevent за допомогою php, але, щоб його зібрати, нам, можливо, знадобиться утиліта phpize з пакета php-devel. Втім, ця обставина нас не повинно зупиняти.
$ Sudo aptitude install php5-dev
Це природно для користувачів Debian або Ubuntu. Якщо у вас Red Hat, Fedora або CentOS, команда буде:
$ Sudo yum install php53-devel
Якщо ви використовуєте Windows ... ну, в загальному, краще поставити віртуальну машину.
Далі встановлюємо розширення libevent (сама бібліотека повинна бути вже встановлена):
Pecl install libevent
Після установки необхідно в php. ini прописати наступний рядок, якщо її немає в наявності:
(Нам важливо це зробити для cli-інтерпретатора, тобто шлях до конфігураційного файлу буде виду: / etc / php5 / cli / php. Ini.)
І нарешті, встановлюємо PhpDaemon:
Git clone git: // github. com / kakserpom / phpdaemon. git chmod + x phpdaemon / bin / phpd
Ln - s / usr / local / phpdaemon / bin / phpd / usr / bin / phpd
Ln - s / usr / bin / phpd / etc / init. d / phpd update-rc. d phpd defaults
Хоча з запуском ми напевно поквапилися, і, можливо, в консоль виваляться кілька помилок. Це не біда, зараз все виправимо. Перш за все редагуємо файл конфігурації - phpdaemon / conf / phpd. conf. Він повинен буде виглядати приблизно так:
User root; group root;
ServerStatus Privileged; enable 1; listen-port 8080: ExampleWebSocket Path / usr / local / lib / phpdaemon / applications / ExampleWebSocket. php: Listenport 8047; user www; WebSocketOverCOMET Path = / usr / local / lib / phpdaemon / AppResolver. php Include conf. d / *. conf: Я тут не буду зупинятися на деталях настройки середовища phpdaemon, весь конфігураційний файл я привожу тільки для того, щоб його можна було без змін використовувати в своїх дослідах читачеві. Найбільш важливі конструкції Server і Example-WebSocket. Перша з них вимикає веб-сокети, друга реєструє тестове додаток. Параметр path вказує на його фізичне розміщення. Дуже важливим параметром конфігурації є рядок Path = / usr / local / lib / phpdaemon / AppResolver. php, Показує наш шлях до ні перетворювати-файлу (файлу, разбирающего запити і зв'язує їх з додатком). Сам цей файл у нас буде максимально простий: Тепер ми перейнятися клієнтською частиною. У дистрибутив phpdae-mon входить хороший інструментарій для тестування технологій. В папці phpdaemon / clientside-connectors / websocket / знаходяться набір js-файлів і приклад html-сторінки, що працює з веб-сокетами, що вимагає мінімальної настройки (рис. 105). Причому для браузерів, які не підтримують WebSocket, виконана емуляція процесу з використанням технологій COMET / Long Pooling і навіть flash. Але нам це не дуже цікаво, не шукатимемо легких шляхів і напишемо свій WebSocket-клієнт: Function messageEvent (msg) Function closeEvent () Мал. 105. Працюємо з WebSockets Тут ми бачимо три кнопки, перша з яких створює сокет (і, відповідно, встановлює з'єднання), викликаючи функцію WebSocketConnection, яка, в свою чергу, створює об'єкт WebSocket (), параметром конструктора якого є url нашого WebSocket-додатки. Другий, необов'язковий параметр - протокол, їх може бути кілька. Після установки з'єднання (нас сповістить про це відповідний alert) можна скористатися кнопкою Send ping, яка посилає повідомлення в сокет. При отриманні повідомлення з боку сервера спрацьовує подія onmessage, в результаті якого в нашому випадку буде виведено повідомлення з відповіддю сервера (рис. 106). Кнопка Close WebSocket закриває сокет - поле цього взаємодія З сервером припиняється. Дані надсилаються і приймаються у вигляді рядків, але ніщо не заважає обмінюватися і JSON-об'єктами: Function sendText () Type: "message", text: "Hello WebSockets.!", Id: clientID, date: Date. now () WS. send (JSON. stringify (msg)); Мал. 106. Відповідь через WebSocket Словом, все, як у звичайному клієнт-серверному веб-взаємодії. Як виглядає серверна частина, нас, строго кажучи, не повинно цікавити, але давайте поглянемо на її реалізацію просто для загального розвитку. * Called when new frame received. * @param string Frame's contents. * @param integer Frame's type. Public function onFrame ($ data, $ type) Daemon :: log ( 'ExampleWebSocket:' pong 'received by client.');> Перший з них викликається при створенні веб-сокета і повертає об'єкт нового сеансу роботи з ним. Другий є реалізацією цього сеансу і містить метод onFrame, що приймає повідомлення і відсилає відповідь. Що ми можемо тепер отримати, виходячи з наявного арсеналу засобів? Та практично все, перешкод у вигляді HTTP-протоколу більше немає. Вірніше, сам HTTP нікуди не подівся, але особливості його архітектури - більше не перешкода. Перешкода в іншому - слабкою поки підтримці технології як в браузерах, так і на веб-серверах. Але, я думаю, ніхто не сумнівається, що це все тимчасово. Набагато більш істотним виглядає інший, «вроджений» недолік технології - відсутність обмеження терміну життя запиту. Справа в тому, що WebSockets - це TCP-сокет, а не HTTP-запит, він не має природи «запит / відповідь на запит», і це, крім переваг, має і зворотну сторону - незручність роботи сервісів, обмежених одним запитом. Ну що ж, срібної кулі не існує, просто розробнику треба завжди мати на увазі таку поведінку при взаємодії з сервером.
Вам також можуть бути цікаві такі статті: