Использование флэш-сокета с узлом.Яш

Я использую gimite / web-socket-js для реализации WebSocket прошлого просто Chrome и разработки сборок Safari. Я хочу отойти от сервера Ruby и перейти на узел.js. Внезапно он не работает ни в чем, кроме Chrome.

Я подозреваю, что это связано с Политика Флэш-Сокета файл, который мне нужно реализовать. Я хотел бы реализовать это как внешний узел.процесс js, чтобы не мутить с оригинальным приложением. Я с помощью узел-websocket-сервер для реализации протокола WebSocket с узлом.JS и снова, я предпочел бы не связываться с этим или.

казалось, что проще всего было бы запустить flashsocket.js, но это дает мне следующую ошибку:

sys:334
    ctor.prototype = Object.create(superCtor.prototype, {
                            ^
TypeError: Object prototype may only be an Object or null
    at Function.create (native)
    at Object.inherits (sys:334:29)
    at Object.<anonymous> (/Users/me/Projects/testing/websocket/node-websocket-server/flashsocket.js:10:16)
    at Module._compile (node.js:472:23)
    at Module._loadScriptSync (node.js:479:10)
    at Module.loadSync (node.js:349:12)
    at Object.runMain (node.js:532:24)
    at node.js:762:10

здесь мы сталкиваемся с прекрасным узлом cryptic errors.за js любят.

мой вопрос в том, есть ли автономный глобальный флэш-сокет policy server я могу запустить с любого узла.JS или другое приложение? Я понимаю, что мне нужно только, чтобы он находился на порту 843. Или есть другая библиотека WebSocket для Node.js, который будет обрабатывать политику Flash, как это делает сервер Ruby?

3 ответов


запросы Флэш-политики также могут быть отвечены встроенным на том же порту, что и служба WebSockets, которую вы предоставляете. См.это изменение к гнезду.Узел ввода-вывода.модуль js. Он добавляет прослушивание соединения к серверу, который отвечает на запросы сервера политики на том же порту. Таким образом, вам не нужно запускать что-то на порту 843 (который обычно требует привилегий root).

кроме того, вы также можете запустить очень простой (2 строки) сервер запросов политики с помощью socat (при условии, что вы находятся в системе * nix):http://github.com/kanaka/noVNC/blob/master/docs/flash_policy.txt

обновление (ответ @Josh K):

Это распространенное недоразумение, что порт 843 является основным местом для запросов flash-политики, и что запросы того же порта являются резервными и что они медленнее из-за таймаута. Это, вероятно, основано на часто цитируемых http://www.lightsphere.com/dev/articles/flash_socket_policy.html и также потому, что документацию Adobe трудно отследить (и прочитать). Вот документация Adobe по их политике безопасности:http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

в реальности порт 843 служит несколько разные цели из того же ответа порта. Порт 843 предназначен для мета-политики (site-policy). Он имеет приоритет над политикой того же порта. Администратор может использовать его для определения политик flash для вся система и может использовать его, чтобы запретить непривилегированным пользователям разрешать входящие подключения флэш-сокетов. Именно по этой причине он находится на порту 843 (который находится в привилегированном диапазоне), так что только системный администратор может запустить службу на этом порту.

3-секундный тайм-аут применяется только в том случае, когда соединения с портом 843 молча отбрасываются. Это не относится к случаю, когда есть какая-то другая служба, работающая на порту 843, или соединение отклонено (т. е. TCP сброс.) Я использую один и тот же порт все время, и нет заметной задержки только с запуском одного и того же сервера политики портов.

с сервером WebSocket дополнительным преимуществом ответа политики с тем же портом является то, что вы можете более легко координировать конфигурацию исходной политики между политикой flash и рукопожатием WebSockets.


С небольшой помощью от узла.список рассылки js я придумал следующий:

var net = require("net"),
    domains = ["localhost:8081"];

net.createServer(
    function(socket)
    {
        socket.write("<?xml version=\"1.0\"?>\n");
        socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n");
        socket.write("<cross-domain-policy>\n");

        domains.forEach(
            function(domain)
            {
                var parts = domain.split(':');
                socket.write("<allow-access-from domain=\""+parts[0]+"\"to-ports=\""+(parts[1]||'80')+"\"/>\n");
            }
        );

        socket.write("</cross-domain-policy>\n");
        socket.end();   
    }
).listen(843);

Я также написал (краткий) учебник для WebSockets приложений с помощью флэш-сокетов.


лучше переопределить прослушиватели потока (слушатели сокета). В противном случае ваш сервер будет сбой, когда у вас есть какая-то ошибка, как:

ECONNRESET, сброс соединения с помощью peer

пример реализации, чтобы предотвратить это :

socket.setEncoding("utf8");
socket.addListener("end", function () {socket.end();});
socket.addListener("error", function (exception) {socket.end();});
socket.addListener("timeout", function () {socket.end();});
socket.addListener("close", function (had_error) {socket.end();});

см. документацию по адресу:http://nodejs.org/api.html (at " net.Поток")