Сокет на стороне клиента.io без узла.сервер js
использовать сокет.io на стороне клиента, обычно мы запускаем узел.JS server и идите так:
<script src="/socket.io/socket.io.js"></script>
или с определенным портом:
<script src="http://localhost:3700/socket.io/socket.io.js"></script>
вопрос:
необходимо ли использовать node.сервер js для обслуживания socket.io.js ?
...или это возможно
сделайте локальную копию socket.io.js вместо того, чтобы идти на сервер каждый раз, когда нам нужен сокет.Ио?
как, мы идем посмотреть источник и скопировать все мы получили от источника из тега ,
вставить и сохранить его как socket.io-local.js так что в следующий раз мы используем:
<script src="socket.io-local.js"></script>
будет работать ?
обновления
Спасибо за большой ответ каждого,
Я спрашиваю это, потому что в случае, если я участвую, у меня на самом деле нет доступа к серверу:
Я пишу на стороне клиента для подключения к сокету другого разработчика, который написан в Ява.
поэтому мне придется подумать, как обойти тот факт, что у меня нет сервера для меня.
от того, что я тестировал, кажется, это работает, но я действительно не знаю, что происходит за сценой.
3 ответов
вы можете хоста розетка.io клиентская библиотека в любом месте и вытащить его на страницу. Тем не менее, это почти наверняка не работает С вашим Java-сервером.
чтобы понять, почему, вам нужно понять, какой сокет.io действительно делает за кулисами; клиентская библиотека-это только небольшая его часть.
гнездо.io фактически определяет и реализует свой собственный протокол для связи в реальном времени между a браузер и сервер. Он делает это таким образом, что поддерживает несколько транспорта: если, например, браузер или прокси-сервер не поддерживает WebSockets, он может вернуться к опроса.
какой сокет.клиент ввода-вывода на самом деле делает это:
- делает XHR
GET
запрос/socket.io/1
. Сервер отвечает идентификатором сеанса, настроенными тайм-аутами и поддерживаемыми транспортами. - клиент выбирает лучший транспорт, который поддерживает браузер пользователя. В современных браузерах, он будет использовать WebSockets.
- если WebSockets поддерживаются, он создает новый
WebSocket
для инициирования подключения WebSocket (HTTPGET
сUpgrade: websocket
заголовок) на специальный URL -/socket.io/1/websocket/<session id>
. - если WebSockets не поддерживаются браузером или не удается подключиться (в дикой природе есть много посредников, таких как прокси, фильтры, устройства сетевой безопасности и т. д., которые не поддерживают Запросы WebSocket), библиотека возвращается к длинному опросу XHR и делает запрос XHR на
/socket.io/1/xhr-polling/<sesion id>
. Сервер не отвечает на запрос, пока не будет доступно новое сообщение или не будет достигнут тайм-аут, после чего клиент повторяет запрос XHR.
гнездо.серверный компонент io обрабатывает другой конец этого беспорядка. Он обрабатывает все URL-адреса в разделе /socket.io/
, настройка сеансов, разбор обновлений WebSocket, фактически отправка сообщений и куча других счетоводство.
без всех услуг, предоставляемых сокетом.io server, клиентская библиотека довольно бесполезна. Он просто сделает запрос XHR на URL-адрес, который не существует на вашем сервере.
Я предполагаю, что ваш Java-сервер просто реализует протокол WebSockets. Вы можете подключиться непосредственно к нему с помощью API WebSocket, предоставляемые браузером.
это возможно что ваш сервер реализует сокет.io протокол – для этого есть несколько заброшенных Java-проектов – но это маловероятно. Поговорите с разработчиком вашего сервера, чтобы узнать, как именно он реализовал " сервер сокетов."
автономная сборка сокета.io-клиент автоматически предоставляется сокетом.сервер ввода-вывода Как
/socket.io/socket.io.js
. В качестве альтернативы вы можете служить файлsocket.io-client.js
найдено в корне этот репозиторий.
https://github.com/LearnBoost/socket.io-client
у меня есть модуль под названием дробовик-клиент это фактически обертывает сокет.Ио. Мне нужно было обслуживать пользовательский клиентский скрипт, а также сокет.сценарий клиента ввода-вывода, но Я не хотел, чтобы каждый пользователь моего модуля включал несколько ссылок на сценарии на своих страницах.
я обнаружил, что при установке вы можете обслуживать сгенерированный клиентский скрипт из сокета.io by чтение файла /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js
. Поэтому мой модуль добавляет прослушиватель для своего собственного URL-адреса, и когда он обслуживает мой пользовательский клиентский скрипт, он также служит сокету.IO клиентский скрипт с ним. Виола! Только одна ссылка на скрипт для пользователей моего модуля:)
хотя это технически возможно, я не понимаю, зачем вам это делать. Если вы обеспокоены уменьшением данных, которые идут по проводу, это изменение фактически не будет делать ничего, кроме нескольких символов, сохраненных в shorter src
тег. Простое изменение местоположения файла JS на сервере фактически не улучшит производительность - JS должен быть отправлен.
правильное кэширование (какой сокет.IO имеет) вернет 304 не измененный (и не повторно отправляет файл JS каждый раз, когда вы загрузить страницу).