Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 87 posts

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

#21

Post by Thaxll »

alexhultman wrote: post #14
e12e wrote: post #6

Earlier quoted context omitted.

Maybe uvloop? "Uvloop: Fast Python networking" https://news.ycombinator.com/item?id=11625585 Maybe paired with Growler: "Growler: Asyncio Micro-Framework in Python" https://news.ycombinator.com/item?id=11632181 "Simple websocket server with uvloop.": https://gist.github.com/kracekumar/daf10b3be3191a78b037c0c79...

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

Because Nodejs is known to be highly performant with its single thread model...

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

#22

Post by justsaysmthng »

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..

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

#24

Post by hendzen »

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 compiled with ASAN and run under something like afl-fuzz.

Also - why do you take a libuv dependency - then use uv_poll_t directly with raw send/recv calls instead of using uv's provided TCP primitives?

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

#25

Post by samsonradu »

131hn wrote: post #16
samsonradu wrote: post #11

Earlier quoted context omitted.

Something like this [1]. It can go over 20fps and looks pretty smooth on iOS devices, no sound though. [1] http://phoboslab.org/log/2013/09/html5-live-video-streaming-...

May i suggest you to take a look on https://github.com/131/h264-live-player (with ws :p)

Thanks, taking a look now.

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

#26

Post by e12e »

alexhultman wrote: post #14
e12e wrote: post #6

Earlier quoted context omitted.

Maybe uvloop? "Uvloop: Fast Python networking" https://news.ycombinator.com/item?id=11625585 Maybe paired with Growler: "Growler: Asyncio Micro-Framework in Python" https://news.ycombinator.com/item?id=11632181 "Simple websocket server with uvloop.": https://gist.github.com/kracekumar/daf10b3be3191a78b037c0c79...

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

"TL;DR

asyncio is an asynchronous I/O framework shipping with the Python Standard Library. In this blog post, we introduce uvloop: a full, drop-in replacement for the asyncio event loop. uvloop is written in Cython and built on top of libuv.

uvloop makes asyncio fast. In fact, it is at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework. The performance of uvloop-based asyncio is close to that of Go programs."

The question asked was if there is "anything [similar in] python", so there's an obvious requirement of being able to use it from python. That leaves either something with a bit of a friendly python wrapper, or just calling out directly to (only) pure C/C++ code. The latter might be even faster, but at that point it's questionable if calling it from python really is worth the trouble at all.

So, I think it's fair to say that "uvloop may be 'something [similar in]' python".

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

#27

Post by alexhultman »

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…

If you allocate the buffer as a char * you should delete it as a char *. Thank you for the kind words.

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

#28

Post by alexhultman »

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…

Also - this server passes the entire Autobahn with no fails, passes Engine.IO tests, Primus tests and exits gracefully with no Valgrind issues. Also, it builds with no warnings. Also, it has been running for weeks stable.

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

#29

Post by IIlllIllIIIIlII »

alexhultman wrote: post #28
hendzen wrote: post #24

Earlier quoted context omitted.

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…

Also - this server passes the entire Autobahn with no fails, passes Engine.IO tests, Primus tests and exits gracefully with no Valgrind issues. Also, it builds with no warnings. Also, it has been running for weeks stable.

Can I ask why you choose to implement your own queue when many exist within C++? (e.g. using queue or list)

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

#30

Post by alexhultman »

IIlllIllIIIIlII wrote: post #29
alexhultman wrote: post #28

Earlier quoted context omitted.

Also - this server passes the entire Autobahn with no fails, passes Engine.IO tests, Primus tests and exits gracefully with no Valgrind issues. Also, it builds with no warnings. Also, it has been running for weeks stable.

Can I ask why you choose to implement your own queue when many exist within C++? (e.g. using queue or list )

Memory footprint and performance.

This implementation is way, way more lightweight. And it assumes that the buffer being queued has a struct Message in its head, so it doesn't have to allocate a node - one memory allocation is therefore skipped.

Post reply on HN