SockJS is a browser JavaScript library that provides a WebSocket-like object. SockJS gives you a coherent, cross-browser, Javascript API which creates a low latency, full duplex, cross-domain communication channel between the browser and the web server.
Under the hood SockJS tries to use native WebSockets first. If that fails it can use a variety of browser-specific transport protocols and presents them through WebSocket-like abstractions.
SockJS is intended to work for all modern browsers and in environments which don't support the WebSocket protocol -- for example, behind restrictive corporate proxies.
SockJS-client does require a server counterpart:
- SockJS-node is a SockJS server for Node.js.
Philosophy:
- The API should follow HTML5 Websockets API as closely as possible.
- All the transports must support cross domain connections out of the box. It's possible and recommended to host a SockJS server on a different server than your main web site.
- There is support for at least one streaming protocol for every major browser.
- Streaming transports should work cross-domain and should support cookies (for cookie-based sticky sessions).
- Polling transports are used as a fallback for old browsers and hosts behind restrictive proxies.
- Connection establishment should be fast and lightweight.
- No Flash inside (no need to open port 843 - which doesn't work through proxies, no need to host 'crossdomain.xml', no need to wait for 3 seconds in order to detect problems)
Subscribe to SockJS mailing list for discussions and support.
SockJS family:
- SockJS-client JavaScript client library
- SockJS-node Node.js server
- SockJS-erlang Erlang server
- SockJS-cyclone Python/Cyclone/Twisted server
- SockJS-tornado Python/Tornado server
- SockJS-twisted Python/Twisted server
- SockJS-aiohttp Python/Aiohttp server
- Spring Framework Java client & server
- vert.x Java/vert.x server
- Xitrum Scala server
- Atmosphere Framework JavaEE Server, Play Framework, Netty, Vert.x
- Actix SockJS Rust Server, Actix Framework
Work in progress:
- SockJS-ruby
- SockJS-netty
- SockJS-gevent (SockJS-gevent fork)
- pyramid-SockJS
- wildcloud-websockets
- wai-SockJS
- SockJS-perl
- SockJS-go
SockJS mimics the WebSockets API,
but instead of WebSocket there is a SockJS Javascript object.
First, you need to load the SockJS JavaScript library. For example, you can put that in your HTML head:
<script src="https://cdn.jsdelivr.net/npm/sockjs-client@1/dist/sockjs.min.js"></script>After the script is loaded you can establish a connection with the SockJS server. Here's a simple example:
var sock = new SockJS('https://mydomain.com/my_prefix');
sock.onopen = function() {
console.log('open');
sock.send('test');
};
sock.onmessage = function(e) {
console.log('message', e.data);
sock.close();
};
sock.onclose = function() {
console.log('close');
};Similar to the 'WebSocket' API, the 'SockJS' constructor takes one, or more arguments:
var sockjs = new SockJS(url, _reserved, options);url may contain a query string, if one is desired.
Where options is a hash which can contain:
-
server (string)
String to append to url for actual data connection. Defaults to a random 4 digit number.
-
transports (string OR array of strings)
Sometimes it is useful to disable some fallback transports. This option allows you to supply a list transports that may be used by SockJS. By default all available transports will be used.
-
sessionId (number OR function)
Both client and server use session identifiers to distinguish connections. If you specify this option as a number, SockJS will use its random string generator function to generate session ids that are N-character long (where N corresponds to the number specified by sessionId). When you specify this option as a function, the function must return a randomly generated string. Every time SockJS needs to generate a session id it will call this function and use the returned string directly. If you don't specify this option, the default is to use the default random string generator to generate 8-character long session ids.
Although the 'SockJS' object tries to emulate the 'WebSocket' behaviour, it's impossible to support all of its features. An important SockJS limitation is the fact that you're not allowed to open more than one SockJS connection to a single domain at a time. This limitation is caused by an in-browser limit of outgoing connections - usually browsers don't allow opening more than two outgoing connections to a single domain. A single SockJS session requires those two connections - one for downloading data, the other for sending messages. Opening a second SockJS session at the same time would most likely block, and can result in both sessions timing out.
Opening more than one SockJS connection at a time is generally a bad practice. If you absolutely must do it, you can use multiple subdomains, using a different subdomain for every SockJS connection.
< 8000 div class="markdown-heading" dir="auto">