uWebSockets: Scalable WebSocket server library for Node.js and C++11 • Hacker News Board

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

#81

Post by Matthias247 » Fri, May 20, 2016, 8:18 PM UTC

alexhultman wrote: post #72

Matthias247 wrote: post #53

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 th…

The server is async, so there is no blocking functions exposed. It passes all Autobahn tests, meaning it properly handles close frames & pings etc. Timers are used to force close connections. The C++ HTTP server does not currently time out, but the Node.js HTTP server does, so this is one issue that needs to be fixed, yes.

Just looked at the code. You seem to queue everything and therefore never block. That can be OK for some use-cases, but you don't provide any kind of backpressure due to that in the send command. It will get problematic in case of slow receivers. And in node it will break the stream semantics. E.g. if someone pipes 1Gb of messages into your socket (or sends them if WriteableStream is not supported) he will think that they have been sent immediatly and won't know that the data is buffered on lower layer. If you pipe a fast source into a slow receiver it will break over time - which is exactly the thing that node streams actually try to avoid.

And another thing I saw there: Your SHORT_SEND optimization looks broken, as there does not seem to be tracked if the buffer is already used by another message that is still queued for sending. So short messages can corrupt each other.

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

#82

Post by jacobwcarlson » Sat, May 21, 2016, 12:05 AM UTC

hendzen wrote: post #24

justsaysmthng wrote: post #22

In https://github.com/alexhultman/uWebSockets/blob/master/src/u... What's the deal with delete [] (char *) head; where `head` is of type `struct Message` ? Is this some kind of performance trick ?... Otherwise it looks kind of suspicious..

yeah - the C++ bits were clearly written by someone who doesn't know the language well. I'd be careful about using this code in production. EDIT: Specifically I'm referring to the usage of raw pointers, unchecked pointer arithmetic, goto for flow control and raw new/delete calls. The author says they have run tests under valgrind, but that doesn't say anything unless the inputs were malicious. Ideally it should be co…

There are many improvements that could be made to this code. However the developer is extremely antagonistic and unwilling to accept criticism so I doubt that the issues will ever be fixed.

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

#83

Post by alexhultman » Sat, May 21, 2016, 8:05 AM UTC

Matthias247 wrote: post #81

alexhultman wrote: post #72

Earlier quoted context omitted.

The server is async, so there is no blocking functions exposed. It passes all Autobahn tests, meaning it properly handles close frames & pings etc. Timers are used to force close connections. The C++ HTTP server does not currently time out, but the Node.js HTTP server does, so this is one issue that needs to be fixed, yes.

Just looked at the code. You seem to queue everything and therefore never block. That can be OK for some use-cases, but you don't provide any kind of backpressure due to that in the send command. It will get problematic in case of slow receivers. And in node it will break the stream semantics. E.g. if someone pipes 1Gb of messages into your socket (or sends them if WriteableStream is not supported) he will think that…

I can assure you, the short send optimization is not broken.

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

#84

Post by Matthias247 » Sat, May 21, 2016, 9:42 AM UTC

alexhultman wrote: post #83

Matthias247 wrote: post #81

Earlier quoted context omitted.

Just looked at the code. You seem to queue everything and therefore never block. That can be OK for some use-cases, but you don't provide any kind of backpressure due to that in the send command. It will get problematic in case of slow receivers. And in node it will break the stream semantics. E.g. if someone pipes 1Gb of messages into your socket (or sends them if WriteableStream is not supported) he will think that…

I can assure you, the short send optimization is not broken.

Ok, the buffer seems tob be copied it in the queuing code if it needs to be queued. That's fine.

But it would have been helpful to point to that code lines instead of only "assuring".

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

#85

Post by barkingdog » Sun, May 22, 2016, 12:59 AM UTC

alexhultman wrote: post #42

barkingdog wrote: post #31

Earlier quoted context omitted.

I can understand that you might be a bit frustrated right now, because perhaps that level of performance in pure python may literally be difficult to impossible in this case. But, the question the person was asking was a very reasonable one -- something along the lines of "I'm using this solution in python right now, and I'd like more performance -- what are my options?" It seems like you not only misunderstand the q…

Toss a coin and it will land on someones holy ground.. My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.

You've written what potentially appears to be a promising library. Great! In fact, it seems so promising that people are trying to find the equivalent in the language of their choice. Even better! Why not encourage them to write a wrapper for your fine library in their language of choice? Not everyone uses Node, after all. Maybe that person asking for equivalents in Python would've written a binding if you told them "Hey, you could try to do this in pure python but because of the relative performance of my library, you might want to consider writing a binding to µws."

I doubt you are trying to harm anyone. But you're not being very helpful. You say that you've "landed on someone's holy ground" but there is a very low chance that is going on. They probably just want to get a job done, and they want to figure out if your tool's a good fit. All it takes is a little bit more thought before you type out a response.

I'm not telling you to censor yourself. I'm telling you to stop worrying about explaining yourself, and start thinking about being more helpful. I'm telling you to do it, because it will make things easier for you. You might have written the library, but other people are going to be the ones who use it. They're going to ask you questions, and you're going to think some of those questions are stupid. It's okay. But if you try to be helpful to them even if you think their questions are stupid, you'll spend far less time writing defensive comments on HN, and far more time watching adoption for your library grow, which I assume is something you may want.

Best of luck!

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

#86

Post by alexhultman » Sun, May 22, 2016, 5:19 PM UTC

meir_yanovich wrote: post #80

What is the main difference between libwebsockets and this ? can it be embedded in to libuv? in C

You can create a C binding and it does integrate with libuv.

libwebsockets is targeting the embedded world with a smaller code footprint (libc vs libstdc++). libwebsockets performs very good in memory and CPU time.

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

#87

Post by alexhultman » Sun, May 22, 2016, 5:27 PM UTC

barkingdog wrote: post #85

alexhultman wrote: post #42

Earlier quoted context omitted.

Toss a coin and it will land on someones holy ground.. My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.

You've written what potentially appears to be a promising library. Great! In fact, it seems so promising that people are trying to find the equivalent in the language of their choice. Even better! Why not encourage them to write a wrapper for your fine library in their language of choice? Not everyone uses Node, after all. Maybe that person asking for equivalents in Python would've written a binding if you told them…

Thanks, I can certainly help people with questions if they need help in writing a Python wrapper. I think that would be a good solution but it would need to integrate seamlessly with the rest of their app. Posting on GitHub would be a good start in this, or Gitter.