alexhultman

10 ms·

61.
Node.js: uWebSockets 0.8.0 adds Windows support(github.com)
34 points by alexhultman 10y ago|5 comments
62.
by alexhultman 10y ago
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
63.
by alexhultman 10y ago
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.
64.
by alexhultman 10y ago
I can assure you, the short send optimization is not broken.
65.
by alexhultman 10y ago
Libuv is definitely not as "screamingly fast" as it's marketing tells. I found the biggest flaw with libuv to be the uv_tcp_t which forces you to have a user space buffer to receive the data, something not needed when using u
66.
by alexhultman 10y ago
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
67.
by alexhultman 10y ago
I want to thank all people involved in making this open source project possible. Things are by far not set in stone and this library has only been in development for about 2 months now. We are working with SocketCluster to make µWS default
68.
by alexhultman 10y ago
Yes, my friend. This guy is trying to roast the library based on bullshit warnings that normal projects (Node.js as one example) explicitly disable. So if you want to make a case out of this, you will have to report this "issue" t
69.
by alexhultman 10y ago
So you enabled pedantic warning level, and you got a bunch of pedantic nonsense warnings. There is a reason for these not to be enabled by default. * Unused parameter -> rly? Who gives a damn? * Use of old style cast -> Well I'm
70.
by alexhultman 10y ago
According to logic, this quote "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." is a personal attack. I get offended by this,
71.
by alexhultman 10y ago
Yes it would cause undefined behavior but empty() is checked before popping.
72.
by alexhultman 10y ago
WARNING ----> NO OFFENCE: You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while. This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tc
73.
by alexhultman 10y ago
Node.js has nothing to do with the performance of this server.
74.
by alexhultman 10y ago
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 offenc
75.
by alexhultman 10y ago
I don't think so but Meatier ( https://github.com/mattkrick/meatier ) should receive uws as default engine since it build on SC, you could look into that but honestly I don't understand this project at all :P
76.
by alexhultman 10y ago
Nope, only ws <-> uws :(
77.
by alexhultman 10y ago
Yes, I use uv_poll_t instead of uv_tcp_t because of massive memory and performance differences. Every decision made, has been made from a performance perspective.
78.
by alexhultman 10y ago
1. It has been compiled with ASAN. 2. What you suggest would blow the memory footprint 16x. Thanks for giving your infinite enlightenment, after looking at my code for 10 minutes. I guess your 10 minutes of reading the code is infinitely mu
79.
by alexhultman 10y ago
Yes, Socket.IO really need to step up their game if they are going to have this kind of marketing: "FEATURING THE FASTEST AND MOST RELIABLE REAL-TIME ENGINE" Never mind the fact that one libuv tcp stream consumes more memory than
80.
by alexhultman 10y ago
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 therefor
81.
by alexhultman 10y ago
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.
82.
by alexhultman 10y ago
If you allocate the buffer as a char * you should delete it as a char *. Thank you for the kind words.
83.
by alexhultman 10y ago
Yep, thanks for being one of the first adopters :) Like mentioned, it works as an optional engine in Socket.IO, Primus & SocketCluser (in which it will be default in version 5). No code change, swap when you feel lucky :P
84.
by alexhultman 10y ago
https://www.youtube.com/watch?v=fN1WBgS9u_E
85.
by alexhultman 10y ago
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.
86.
by alexhultman 10y ago
I get this question quite often, here is a good start: https://github.com/alexhultman/uWebSockets/issues/56
87.
by alexhultman 10y ago
I think the best solution would be to write a Python binding to µWS. You will not be able to implement this perf / memory footprint in Python itself.
88.
by alexhultman 10y ago
There is nothing new brought to the table, feature wise. Same old ws interface, you keep your current code unchanged. Swap require('ws') with require('uws') and see how it works for your code, report any issues if you ne
89.
uWebSockets: Scalable WebSocket server library for Node.js and C++11(github.com)
108 points by alexhultman 10y ago|80 comments