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

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?