> A noisy client will be able to crash our server, as c.write is non-blocking and will buffer an infinite amount of data in memory (this can be partially solved with a node.js Stream API, more on that later).
This doesn't make any sense at all.
First, c.write would not buffer what the other server sends. It only takes what you give it. Maybe that was a typo.
Second, non-blocking and buffering are practically in perfect opposition to each other. For a system call to buffer an indefinite amount, it would have to block. That's exactly what node was designed to never do. node never buffers anything -- not when I tried it, at least. If the client sent a long stream of data, node would call the read callback every time the kernel received a packet or a kernel buffer filled up. c.write() would return immediately every time, and a return packet would get sent out. Nothing bad would happen.
This doesn't make any sense at all.
First, c.write would not buffer what the other server sends. It only takes what you give it. Maybe that was a typo.
Second, non-blocking and buffering are practically in perfect opposition to each other. For a system call to buffer an indefinite amount, it would have to block. That's exactly what node was designed to never do. node never buffers anything -- not when I tried it, at least. If the client sent a long stream of data, node would call the read callback every time the kernel received a packet or a kernel buffer filled up. c.write() would return immediately every time, and a return packet would get sent out. Nothing bad would happen.