engine.io-parser
Advanced tools
The engine.io-parser npm package is designed for encoding and decoding packets used by engine.io, which is a transport layer for real-time data exchange between a client and a server. It handles the framing of messages for transport over various real-time protocols and supports binary data.
Encoding messages
This feature allows you to encode a message packet into a format suitable for transport over the network. The `encodePacket` function takes a packet object and a callback function that receives the encoded packet.
const { encodePacket } = require('engine.io-parser');
const packet = { type: 'message', data: 'hello' };
encodePacket(packet, false, (encodedPacket) => {
// handle the encoded packet
});Decoding messages
This feature allows you to decode a message packet that was received from the network. The `decodePacket` function takes an encoded packet and the type of data ('string' or 'binary') and returns the decoded packet object.
const { decodePacket } = require('engine.io-parser');
const encodedPacket = '2hello'; // example of an encoded message packet
const packet = decodePacket(encodedPacket, 'string');
// handle the decoded packetSupport for binary data
This feature provides support for encoding and decoding binary data. The `encodePacket` and `decodePacket` functions can handle binary data when the second argument is set to `true` for binary.
const { encodePacket, decodePacket } = require('engine.io-parser');
const binaryData = new ArrayBuffer(100);
const packet = { type: 'message', data: binaryData };
encodePacket(packet, true, (encodedPacket) => {
// handle the encoded packet with binary data
});
const decodedPacket = decodePacket(encodedPacket, 'binary');
// handle the decoded packet with binary dataThe 'ws' package provides a WebSocket client and server implementation. It allows for real-time communication similar to engine.io-parser but is focused on the WebSocket protocol specifically, whereas engine.io-parser is part of the engine.io ecosystem which can fall back to other transport mechanisms if WebSockets are not available.
The 'socket.io-parser' is used by Socket.IO to encode and decode messages. It is similar to engine.io-parser but is tailored for the Socket.IO framework, which builds on top of engine.io to provide additional features like rooms, namespaces, and middleware support.
The 'json-socket' package is a wrapper around the Node.js net library that adds a layer for seamless JSON message sending. It is similar to engine.io-parser in that it handles message framing, but it is specifically designed for TCP sockets and does not support the variety of transport layers that engine.io-parser does.
This is revision 3 of the Engine.IO protocol.
open packet with JSON-encoded handshake data:sid session id (String)upgrades possible transport upgrades (Array of String)pingTimeout server configured ping timeout, used for the client
to detect that the server is unresponsive (Number)ping packets sent by the server
with pong packets.message packets at will.close packet to close the socket, since
they're expected to be "opening" and "closing" all the time.An Engine.IO url is composed as follows:
/engine.io/ [ ? ]
The engine.io pathname should only be changed by higher-level
frameworks whose protocol sits on top of engine's.
The query string is optional and has four reserved keys:
transport: indicates the transport name. Supported ones by default are
polling, flashsocket, websocket.j: if the transport is polling but a JSONP response is required, j
must be set with the JSONP response index.sid: if the client has been given a session id, it must be included
in the querystring.b64: if the client doesn't support XHR2, b64=1 is sent in the query string
to signal the server that all binary data should be sent base64 encoded.FAQ: Is the /engine.io portion modifiable?
Provided the server is customized to intercept requests under a different path segment, yes.
FAQ: What determines whether an option is going to be part of the path
versus being encoded as part of the query string? In other words, why
is the transport not part of the URL?
It's convention that the path segments remain only that which allows to
disambiguate whether a request should be handled by a given Engine.IO
server instance or not. As it stands, it's only the Engine.IO prefix
(/engine.io) and the resource (default by default).
There's two distinct types of encodings
An encoded packet can be UTF-8 string or binary data. The packet encoding format for a string is as follows
<packet type id>[<data>]
example:
2probe
For binary data the encoding is identical. When sending binary data, the packet type id is sent in the first byte of the binary contents, followed by the actual packet data. Example:
4|0|1|2|3|4|5
In the above example each byte is separated by a pipe character and shown as an integer. So the above packet is of type message (see below), and contains binary data that corresponds to an array of integers with values 0, 1, 2, 3, 4 and 5.
The packet type id is an integer. The following are the accepted packet types.
Sent from the server when a new transport is opened (recheck)
Request the close of this transport but does not shutdown the connection itself.
send by the server. Client should answer with a pong packets, containing the same data
example
2probe3probesend by the client to respond to ping packets.
actual message, client and server should call their callbacks with the data.
4HelloWorldsocket.on('message', function (data) { console.log(data); });4HelloWorldsocket.on('message', function (data) { console.log(data); });Before engine.io switches a transport, it tests, if server and client can communicate over this transport. If this test succeed, the client sends an upgrade packets which requests the server to flush its cache on the old transport and switch to the new transport.
A noop packet. Used primarily to force a poll cycle when an incoming websocket connection is received.
2probe3probe5A payload is a series of encoded packets tied together. The payload encoding format is as follows when only strings are sent and XHR2 is not supported:
<length1>:<packet1>[<length2>:<packet2>[...]]
When XHR2 is not supported, the same encoding principle is used also when
binary data is sent, but it is sent as base64 encoded strings. For the purposes of decoding, an identifier b is
put before a packet encoding that contains binary data. A combination of any
number of strings and base64 encoded strings can be sent. Here is an example of
base 64 encoded messages:
<length of base64 representation of the data + 1 (for packet type)>:b<packet1 type><packet1 data in b64>[...]
When XHR2 is supported, a similar principle is used, but everything is encoded directly into binary, so that it can be sent as binary over XHR. The format is the following:
<0 for string data, 1 for binary data><Any number of numbers between 0 and 9><The number 255><packet1 (first type, then data)>[...]
If a combination of UTF-8 strings and binary data is sent, the string values are represented so that each character is written as a character code into a byte.
The payload is used for transports which do not support framing, as the polling protocol for example.
An engine.io server must support three transports:
The polling transport consists of recurring GET requests by the client to the server to get data, and POST requests with payloads from the client to the server to send data.
The server must support CORS responses.
The server implementation must respond with valid JavaScript. The URL
contains a query string parameter j that must be used in the response.
j is an integer.
The format of a JSONP packet.
`___eio[` <j> `]("` <encoded payload> `");`
To ensure that the payload gets processed correctly, it must be escaped in such a way that the response is still valid JavaScript. Passing the encoded payload through a JSON encoder is a good way to escape it.
Example JSONP frame returned by the server:
___eio[4]("packet data");
The client posts data through a hidden iframe. The data gets to the server in the URI encoded format as follows:
d=<escaped packet payload>
In addition to the regular qs escaping, in order to prevent
inconsistencies with \n handling by browsers, \n gets escaped as \\n
prior to being POSTd.
Encoding payloads should not be used for WebSocket, as the protocol already has a lightweight framing mechanism.
In order to send a payload of messages, encode packets individually
and send() them in succession.
A connection always starts with polling (either XHR or JSONP). WebSocket gets tested on the side by sending a probe. If the probe is responded from the server, an upgrade packet is sent.
To ensure no messages are lost, the upgrade packet will only be sent once all the buffers of the existing transport are flushed and the transport is considered paused.
When the server receives the upgrade packet, it must assume this is the new transport channel and send all existing buffers (if any) to it.
The probe sent by the client is a ping packet with probe sent as data.
The probe sent by the server is a pong packet with probe sent as data.
Moving forward, upgrades other than just polling -> x are being considered.
The client must use the pingTimeout sent as part of the handshake (with
the open packet) to determine whether the server is unresponsive.
If no packet type is received withing pingTimeout, the client considers
the socket disconnected.
FAQs
Parser for the client for the realtime Engine
The npm package engine.io-parser receives a total of 5,868,029 weekly downloads. As such, engine.io-parser popularity was classified as popular.
We found that engine.io-parser demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.