travis ci build doesn't work now.
maybe service hook for travis is deactived?

Due to the nature of data being transmitted, message packets with a binary payload need different handling (identifying, encoding, decoding). This is already being done, but the specification attempts to make these types agree by attempting to bunch them together under a single packet message with ID 4, but the same specification, on the other hand, also identifies binary packets differently (using a b character).

So, given that not only are the packets handled differently, stored differently, but also is identified differently and transmitted differently (binary packets have MIME type application/octet-stream, text packets have MIME type text/plain), wouldn't it simply make more sense to have two message packet types, rather than trying hard to make them coexist under a single packet type as is currently being done?

I have a c# implementation that should work with both v3 and v4. Because v4 has a few breaking changes, i can't implement them in a backward compatible way and different code must be executed based on the version of the server.

Conversely, if the client does not receive a pong packet within pingInterval + pingTimeout, then it SHOULD consider that the connection is closed.

The Hearbeat section says, server send ping to client, then the client reply a pong to server. So the client should wait for a ping packet, is it a typo or?

what the packet type 42, 428, 429, 4210 mean?

i know 4 is a message, but the 2, 28, 29, 210 ？？

Although I can interpret from the source code and its comments, I feel I still need a clear document on WebTransport communication.🤔

In fact, the pong message doesn't contain the message send in ping

Where we can find the pong implement in engine.io:

switch (packet.type) {
      case 'ping':
        debug('got ping');
        this.sendPacket('pong');
        this.emit('heartbeat');
        break;
}

As we can see, it just send the pong message and ignore the ping payload.

Should update document like below:

- Sent by the client. Server should answer with a pong packet containing the same data
+ Sent by the client. Server should answer with a pong packet

client sends: 2probe
- server sends: 3probe
+ server sends: 3

Or change the implement of engine.io to fix this issues?

There should be a branch for each version of the protocol, as there are branches on the engine.io repository for 3.1.x, 2.1.x, etc. I have found it extremely frustrating to develop a client implementation without this necessary information.

I'm the author of go-socket.io. I try to catch up current implement now. And I have some questions need to clarify.

As protocol described not very clear, if a packet is string, the leading type id is "4" in string. And if a packet is binary, the leading type id is a byte 4. Am I right?

So it can use type id to check if a packet is string or binary. Right?

And from implement, it seems only message(type 4) packet could be binary packet. All other types packet are string. So it only have types below:

• "0": open
• "1": close
• "2": ping
• "3": pong
• "4": string message
• byte 4: binary message
• "5": upgrade
• "6": noop

Is it right?

sid: if the client has been given a session id, it must be included in the querystring.

I'm connecting server without this param and it works well, so I'm wondering is this parameter just designed for reconnecting?

Thanks.

From document, the Ping packet is send by server and answered by client. But in implementation, the ping packet send by client and answered by server.

The description of how payloads are encoded is unclear. In particular, how lengths should be encoded is not clear, there is conflicting information, and information that doesn't make sense.

Here are some unanswered questions that the spec leaves begging:

• What is the length when the payload is binary encoded (ie, when XHR2 is supported)? Is it the number of bytes? Is it the number of bytes + 1? Previously, for non XHR2 requests, the length is defined as the number of characters, does that apply to XHR2 requests, or for XHR2 requests is it always the number of bytes?
• For non XHR2 request, should be "b" for binary packets be included in the length or not? If so, then when it says that the length should be the length of the base64 encoded data + 1, that's wrong, because it's +1 for UTF8 packets, but +2 for binary packets.

In the front, I'm not an English native speaker. It may be my misunderstanding. I just want to make it clear.

In Sample session, WebSocket frames show

...
> 5         => "upgrade" packet type
...
> 2         => "ping" packet type

As ping is always sent by server-side and they share the same direction, I read it as upgrade is sent by server-side too. (That direction is different from what it is in the next session, but it doesn't relate with this question.)

In Transport Upgrading, it says

A connection always starts with polling (either XHR or JSONP). WebSocket gets tested on the (client) side by sending a probe. If the probe is responded from the server, an upgrade packet is sent (from which side? Client?).

As it says When the server receives the upgrade packet in the following paragraphs, it conflicts with WebSocket frames.

Could you clarify that the upgrade is sent from client and update the WebSocket frames?

There is no example given of this packet being used.

It should emit a callback with each packet:

decodePayload(packetsString, function(packet, isLast){});

Callback arguments:

• packet just like each item of the returned array right now
• isLast true if it's the last packet in the payload, false otherwise.

Instead of returning an array like it is now.
This will give us the possibility of giving events to the user before all packets are parsed from the string (important for very big payloads).

Let's make sure to add tests for this.

I found in the comments to issue #39 that "[packets]... are encoded... utf8 for text".

I think it would be helpful to add to https://github.com/socketio/engine.io-protocol#packet-encoding

"Packet encoding"

The serialization of an Engine.IO packet depends on the type of the payload (plaintext or binary) and on the transport.

Character encoding is UTF8 for plaintext and for base64-encoded binary payloads.

I can't find information on when JSONP is used and when XHR is used.
I checked the readme's from:

• this repository
• engine.io
• engine.io-client

I think I understand one of these is used when a client is in "polling" mode, but there is little information on why one of these would be selected.
I understand I can force JSONP using the forceJSONP option and I could disable it by setting jsonp to false.

packetslist[type] when calling decodePacket relies on the object keys order. It's ok in almost cases, but better to avoid that anyway, IMHO.

I couldn't find any reference to it in the source. If it has no use, can it be left out?

http://127.0.0.1:3000/socket.io/?EIO=3&transport=polling&t=Lci8wa9&sid=0VstkFt2SKGr0s2WAAAC
what EIO and t mean?

I translate the README.md into Chinese, hope chinese people read it more clearly. but
Some places are still in translation。 this is the url: https://github.com/monokeroslun/engine.io-protocol-cn

In test-suite.js there's a test that checks if the server closes the session and sends a 1 close packet when the client makes duplicate poll requests at the same time here, I have two questions about that:

1. Why is it a problem that the client can make duplicate poll requests?
2. What is the best way for a server to detect that the client made a duplicate poll request i was thinking of doing something with a timestamp we can attach a timestamp to the session and check it when the client makes a poll request.

I'm making my own engine.io implementation and I never done something like this before so i apologize for my ignorance, thanks :).

Currently, the number of characters is used as a prefix for string payloads when XHR2 is not supported.

The meaning of a "character" is not concrete, so I propose using byte lengths and encoding all text using the utf8 package (http://git.io/utf8js).