- Thread Starter
- #26
WebSocket
WebSockets comes with XMPP through RFC 7395. RFC 6455 is the overall WebSocket protocol. This was meant to replace previous technologies of Bidirectional data transfer (including BOSH) over HTTP. It works over TCP, allowing connections in both directions.
wss:// is the URI prefix for secure WebSocket. Data is secured under this transport, and not via frameworks under it. wss shouldn't be redirected to un-secure protocols like ws:// and http://. WebSocket was meant to work under HTTP ports 80 and 443. It is adaptable to have its own ports in the future, and to be improved to have a better handshake.
There were (or are) two ways to use XMPP with WebSocket (XMPP/WS): through a proxy server (like BOSH through a connection manager proxy), or have XMPP integrated with WebSocket at the server. Enabling WebSocket on an XMPP server requires configuration of a module.
WebSocket communications consist of: a handshake, and data transfer. Each XMPP stanza is en-capsuled or carried by 1 WebSocket message. WebSockets also uses pings to maintain or coordinate XMPP connections.
WSAPI is the WebSocket API for joining HTTP web applications to this protocol. For more details on WSAPI: https://www.w3.org/TR/websockets/
Comparisons to BOSH
WebSocket was meant for HTML5, for use with many applications. BOSH was made for XMPP. (BOSH previously replaced Jabber HTTP Polling [XEP-0025])
WebSocket can be used with Javascript. Bosh relies on Javascript with complicated libraries.
WebSocket uses less bytes for a message transfer than BOSH. Bosh uses long polling, and has "high transport overhead compared to XMPP's native binding to TCP." WebSocket overcomes webpolling problems over HTTP. Supposedly, WebSocket uses under 10 bytes of overhead for small messages. BOSH may use over 150 bytes of each pair of request and response headers.
From earlier information I read, it seemed that BOSH was better than WebSockets for intermittent network branches. WebSockets may be better, at least in many ways. WebSocket is “a more elegant, modern and faster replacement to Bosh,” according to ejabberd-websocket's module readme.
Bayeux and Comet were other methods for HTTP that haven't gained as much traction.
Improving Reliability
WebSocket can use Stream Management Extension [XEP-0198] to better manage stream connections, and to help overcome shortcomings compared to BOSH. Stream Management Extension does a good job of managing interrupted (temporary disconnected) connections.
Client State Indication [XEP-0352] also helps on intermittent mobile networks. It allows the server to hold data until mobile client has a better connection.
XMPP Ping Extension [XEP-0199] can also be used, but many browsers aren't compatible with it.
For mobile connections, see: Mobile Considerations on LTE Networks [XEP-0286].
Additional Refs and See also:
* https://stackoverflow.com/questions...all-for-bosh-over-websockets-and-long-polling
* Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP - https://tools.ietf.org/html/rfc6202
* The Definitive Guide to HTML5 WebSocket: [Chapter 4] Building Instant Messaging and Chat over WebSocket with XMPP
* https://www.websocket.org/aboutwebsocket.html
* https://www.websocket.org/quantum.html
WebSockets comes with XMPP through RFC 7395. RFC 6455 is the overall WebSocket protocol. This was meant to replace previous technologies of Bidirectional data transfer (including BOSH) over HTTP. It works over TCP, allowing connections in both directions.
wss:// is the URI prefix for secure WebSocket. Data is secured under this transport, and not via frameworks under it. wss shouldn't be redirected to un-secure protocols like ws:// and http://. WebSocket was meant to work under HTTP ports 80 and 443. It is adaptable to have its own ports in the future, and to be improved to have a better handshake.
There were (or are) two ways to use XMPP with WebSocket (XMPP/WS): through a proxy server (like BOSH through a connection manager proxy), or have XMPP integrated with WebSocket at the server. Enabling WebSocket on an XMPP server requires configuration of a module.
WebSocket communications consist of: a handshake, and data transfer. Each XMPP stanza is en-capsuled or carried by 1 WebSocket message. WebSockets also uses pings to maintain or coordinate XMPP connections.
WSAPI is the WebSocket API for joining HTTP web applications to this protocol. For more details on WSAPI: https://www.w3.org/TR/websockets/
Comparisons to BOSH
WebSocket was meant for HTML5, for use with many applications. BOSH was made for XMPP. (BOSH previously replaced Jabber HTTP Polling [XEP-0025])
WebSocket can be used with Javascript. Bosh relies on Javascript with complicated libraries.
WebSocket uses less bytes for a message transfer than BOSH. Bosh uses long polling, and has "high transport overhead compared to XMPP's native binding to TCP." WebSocket overcomes webpolling problems over HTTP. Supposedly, WebSocket uses under 10 bytes of overhead for small messages. BOSH may use over 150 bytes of each pair of request and response headers.
From earlier information I read, it seemed that BOSH was better than WebSockets for intermittent network branches. WebSockets may be better, at least in many ways. WebSocket is “a more elegant, modern and faster replacement to Bosh,” according to ejabberd-websocket's module readme.
Bayeux and Comet were other methods for HTTP that haven't gained as much traction.
Improving Reliability
WebSocket can use Stream Management Extension [XEP-0198] to better manage stream connections, and to help overcome shortcomings compared to BOSH. Stream Management Extension does a good job of managing interrupted (temporary disconnected) connections.
Client State Indication [XEP-0352] also helps on intermittent mobile networks. It allows the server to hold data until mobile client has a better connection.
XMPP Ping Extension [XEP-0199] can also be used, but many browsers aren't compatible with it.
For mobile connections, see: Mobile Considerations on LTE Networks [XEP-0286].
Additional Refs and See also:
* https://stackoverflow.com/questions...all-for-bosh-over-websockets-and-long-polling
* Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP - https://tools.ietf.org/html/rfc6202
* The Definitive Guide to HTML5 WebSocket: [Chapter 4] Building Instant Messaging and Chat over WebSocket with XMPP
* https://www.websocket.org/aboutwebsocket.html
* https://www.websocket.org/quantum.html