Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed packet send callback issues #130

Merged
merged 1 commit into from
Dec 26, 2012

Conversation

roamm
Copy link
Contributor

@roamm roamm commented Dec 19, 2012

There were two issues here.

  1. When Socket.send called with or without callback alternately, the trigger order is incorrect.
  2. The 'drain' event from transport is one per packet for transports supporting framing like websocket and is all in one for those without framing like polling.

There were two issues here.
1. When Socket.send called with or without callback alternately,
   the trigger order is incorrect.
2. The 'drain' event from transport is one per packet for transports
   supporting framing like websocket and is all in one for those without
   framing like polling.
rauchg added a commit that referenced this pull request Dec 26, 2012
Fixed packet send callback issues
@rauchg rauchg merged commit 3c968fc into socketio:master Dec 26, 2012
@rauchg
Copy link
Contributor

rauchg commented Dec 26, 2012

@roamm this makes a test fail:

  1) server send callback should execute when message sent (polling):
     Error: expected 0 to equal 1
      at Assertion.assert (/Users/guillermorauch/Projects/engine.io/node_modules/expect.js/expect.js:99:13)
      at Assertion.be.Assertion.equal (/Users/guillermorauch/Projects/engine.io/node_modules/expect.js/expect.js:200:10)
      at Assertion.(anonymous function) [as be] (/Users/guillermorauch/Projects/engine.io/node_modules/expect.js/expect.js:73:24)
      at Object.listen.allowUpgrades [as _onTimeout] (/Users/guillermorauch/Projects/engine.io/test/server.js:795:26)
      at Timer.list.ontimeout (timers.js:101:19)

@roamm
Copy link
Contributor Author

roamm commented Jan 16, 2013

@guille I fixed this and added 2 more test cases, in a new pull request.

darrachequesne pushed a commit that referenced this pull request May 8, 2020
use istanbul for code coverage
darrachequesne pushed a commit that referenced this pull request Jun 13, 2024
With the `websocket` transport, the callbacks which indicate that the
packets are actually written were not properly called.

Example:

```js
socket.send("hello", () => {
  // the message has been written to the underlying transport
});
```

The bug was caused by the `websocket` transport (and `webtransport` as
well) having its `supportsFraming` property set to `true`, despite
having been changed in [1] to emit a single `drain` event for each
batch of messages written to the transport like the `polling` transport
always did. Note that although [1] is partially reverted in [2], the
new `drain` event behavior is preserved as called out in that commit's
message.

The `supportsFraming` attribute was introduced in [3] (amended by [4])
as a way to distinguish transports that emit one `drain` per message
from those that emit one `drain` per batch. Since the delivery of
`send` callbacks depends on matching `drain` events with
`transport.send` calls, that distinction is vital to correct behavior.

However, now that all transports have converged to "one `drain` per
batch" behavior, this `supportsFraming` property can be retired (and
the code for calling callbacks simplified).

[1]: #618
[2]: a65a047
[3]: #130
[4]: #132

Related: #698
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants