- Adds new dgram module, for all data-gram type transports
- Supports both UDP client and servers
- Supports Unix Daemon sockets in DGRAM mode too (think syslog)
- Uses a shared Buffer and slices that as needed to be reasonably
performant.
- One supplied test program so far, test-dgram-pingpong
- Passes test cases on osx 10.6 and ubuntu 9.10u
a) create a layer of indirection in net.Stream to allow swapping in
different read/write implementations and
b) emit an 'fd' event when file descriptors are received over a UNIX pipe,
as finally as a tangential benefit
c) remove a bunch of conditionals from the primary codepaths for
ease-of-reading.
This patch makes buffers the preferred output for fs.read() and
fs.readSync(). The old string interface is still supported by
converting buffers to strings dynamically. This allows to remove the
C++ code for string handling which is also part of this patch.
This patch makes buffers the preferred output for fs.read() and
fs.readSync(). The old string interface is still supported by
converting buffers to strings dynamically. This allows to remove the
C++ code for string handling which is also part of this patch.
There is a difference between errors which happen to a socket - like
receiving EPIPE - an exceptional situation but ultimately okay and the
situation where code throws in a callback - which is not okay.
Fixes test/simple/test-http-exceptions.js
TODO: explain this in docs.
Previously path.dirname('/tmp') incorrectly returned '.'.
Unfortunately module.js incorrectly thinks dirname('/a/b/') should
yield '/a/b', so I can't strip trailing slashes yet. Once module.js
is fixed, then the commented-out code should be activated and a test
written for it.
This patch makes buffers the preferred input for fs.write() and
fs.writeSync(). The old string interface is still supported by
converting strings to buffers dynamically. This allows to remove the
C++ code for string handling which is also part of this patch.
Taking a performance hit on 'hello world' benchmark by enabling this by
default, but I think it's worth it. Hopefully we can improve performance by
resetting the timeout less often - ideally a 'hello world' benchmark would
only touch the one timer once - if it runs in less than 2 seconds. The rest
should be just link list manipulations.
- setTimeout should active the timeout too. (test-net-set-timeout tests
this.)
- 'timeout' event is not automatically followed by an 'error' event. That
is the user is now responsible for destroying the stream if there is an
idle timeout.
In ab068db9b1 this test was broken because (I
think) compile/run errors are set to crash the program instead of being
passed back.
Error reporting is more important than remote loading. Disabling until there
is a fix
- No more single line "node.js:176:9" errors
- No more strange output when error happens on first line due to
module wrapper function.
- A few tests to check these things
Ryan Dahl
Micheil Smith
Aaron Heckmann
isaacs
Peter Griess
Felix Geisendörfer
Paul Querna
Orlando Vazquez
Sam Hughes
Aapo Laitinen
Mikeal Rogers
rentzsch
visionmedia
Jonas Pfenniger
Andrew Johnston
Matt Ranney
Elijah Insua
Ben Noordhuis