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

About stream.write() #14

Open
ibc opened this issue Nov 23, 2019 · 1 comment
Open

About stream.write() #14

ibc opened this issue Nov 23, 2019 · 1 comment

Comments

@ibc
Copy link
Contributor

ibc commented Nov 23, 2019

Just wondering how sctp behaves regarding stream.write() method. According to the Node stream.write() documentation:

Returns: false if the stream wishes for the calling code to wait for the 'drain' event to be emitted before continuing to write additional data; otherwise true.

While a stream is not draining, calls to write() will buffer chunk, and return false. Once all currently buffered chunks are drained (accepted for delivery by the operating system), the 'drain' event will be emitted. It is recommended that once write() returns false, no more chunks be written until the 'drain' event is emitted. While calling write() on a stream that is not draining is allowed, Node.js will buffer all written chunks until maximum memory usage occurs, at which point it will abort unconditionally. Even before it aborts, high memory usage will cause poor garbage collector performance and high RSS (which is not typically released back to the system, even after the memory is no longer required). Since TCP sockets may never drain if the remote peer does not read the data, writing a socket that is not draining may lead to a remotely exploitable vulnerability.

So just wondering:

  • Does node-sctp behave the same way?
  • Does write() also return true/false depending on the draining status?
  • Does it emit "drain" events?
  • May the whole Node app abort if it calls write() extensively by ignoring the returned false value?
@latysheff
Copy link
Owner

@ibc unfortunately, as you have seen later, library is not fully compliant with Stream API. I intend to make a major refactoring at some point. Collaborators are more than welcome, meanwhile.

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

No branches or pull requests

2 participants