uWebSockets: Scalable WebSocket server library for Node.js and C++11

That's the kind of stuff that he is talking about...

The snark and sarcasm makes you look incredibly incompetent, and I don't want to touch your code because of it (after all, if you are part of my dependency chain, then you have the ability to sneak in updates, and if you can't even be civil in a comment thread, how do I know you won't attack me through code?).

Hey there. Just wrote down a few things that came to my mind after seeing this. Don't see it as criticism, but as a few hints/remarks what has to be covered by a websocket (or any other protocol) implementation. Imho the high performance part isn't too hard to achieve and shouldn't be the highest rated. The important thing is that such a server should be rock solid in implementation, otherwise it's worthless.

Some things that you should answer if you are offering this as a C++ websocket library, and which are currently not covered in the header file:

    - Whats the threading model of the library?
    - Will server.run() start a singlethreaded eventloop (I guess so from taking a supershort peek into the code and seeing libuv) and everything is running inside there or will it start multiple worker threads?
    - Based on the last question, from which thread[s] are the other callbacks called.
    - If multiple threads are used, is the library threadsafe for sending messages from other threads
    - Is it integratable in other eventloops? Most applications already have a mainloop or something like this, libraries which only work with their own mainloop are not very useful. Normally applications also have to deal with other application logic besides responding to websocket messages.

Besides that a few general questions that you should be able to answer for a websocket implementation:

    - What's the sending behavior of socket.send?
    - Will it block until all data was sent? This can cause problems with slow receivers in singlethreaded environments.
    - Will it copy all data and buffer it internally until it can be sent? This provides no means for backpressure and slow receivers (or non-receivers) can exhaust the servers memory.
    - Does it handle connection close properly? This is unfortunatly not too easy in websockets.
    - And are there timers in place for force closing the connection if the shutdown sequence is not completed properly? Or if the initial handshake is not completed in a given timeframe?
    - Does ist handle control frames? And will it merge control frames (PONGs) if multiple are queued before they are sent? And will it stop sending them after close connection is initiated?

It has been said posting code on HN a literal "Trial By Fire",

But reading the comments in this thread this has gone overboard....to the point I, as a casual observer, had to say something.

I agree, "clearly written by someone who doesn't know the language well", _IS_ a direct attack on the developer and not the code. And I couldn't comprehend the mental gymnastics it would take to explain otherwise.

There is a major difference between:

"Why did you implement your own Queue here?" and "This guy doesn't understand C++. Don't use his code."

Don't let them win by giving into replying with a "Redditor" form of rebuttal filled with snark.

Why is your username green?

Not sure it it helps but it looks like it uses Faye-Websockets

https://github.com/faye/faye-websocket-node

I don't know enough about the inner workings to be able to tell if it's compatible. Any Speeding up of meteor would be HUGE news.