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

Websocketd

websocketd.com

Post reply on HN
Print view View original

141–150 of 233 posts

Re: Websocketd

#141

Post by emj »

lexicality wrote: post #119
vidarh wrote: post #104

Earlier quoted context omitted.

On the contrary. IRC shows that maintaining a consistent network where every part can always reach every other part is tricky, but the most common problem with irc networks is not clients getting booted off, but net-splits that usually automatically resolves pretty quickly. That they're visible to clients is an issue with how channels spans servers and how operator status and channel membership is tied to who happens…

I disagree. I've not seen a netsplit in months, but clients constantly timing out and rejoining is a fact of life.

That is a different problem, clients can always have bad connections that is not solved by UDP/HTTP.

Re: Websocketd

#142

Post by fulafel »

arendtio wrote: post #112
Jedi72 wrote: post #94

Earlier quoted context omitted.

Unless you develop in Elixir/Erlang where you can spawn millions of concurrent processes.

AFAIK, those are not 'processes' in terms of operating system processes, but instead some kind of parallel running tasks within the Erlang VM (much closer to threads). Edit: If you think I am wrong, could you please explain what is wrong?

Traditionally in Unix and Windows contexts, "processes" means separate memory address spaces and OS-guaranteed isolation, and "threads" mean threads of execution that have shared access to one address space.

Erlang processes are threads as seen by the OS, but the Erlang runtime implements process-y restrictions that enforce isolation and forbid shared memory between Erlang processes that do infact exist as threads inside te Erlang VM.

The programming model, as seen by the Erlang/Elixir prgrammer, is thus anologous to Unix processes, just with lower overheads.

Re: Websocketd

#143

Post by walterstucco »

geocar wrote: post #115
jchw wrote: post #26

This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.

The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows

8ms Is eternity

Re: Websocketd

#144

Post by walterstucco »

askmike wrote: post #110
laumars wrote: post #108

Earlier quoted context omitted.

I’ve had developers say this before when building public websites and it has cost us in lost revenue when the site has gone offline or cost us lots in virtual hardware having to scale the number of servers available to meet higher than expected volumes of traffic. Don’t get me wrong, I'm not suggesting that everyone should be building their site like it’s Facebook or Google, but when every public website is already s…

Used in production doesn't always mean used by all users of a public app that might go viral. If you have an app with an admin interface/CMS/monitoring interface and you know there won't be 50 administrators for your app before the end of the year this works great (assuming you can reverse proxy this to add auth or something).

You don't want to pay for more than you really need and don't want to risk a DDOS either. Spikes are not that uncommon

Re: Websocketd

#145

Post by hendry »

emj wrote: post #141
lexicality wrote: post #119

Earlier quoted context omitted.

I disagree. I've not seen a netsplit in months, but clients constantly timing out and rejoining is a fact of life.

That is a different problem, clients can always have bad connections that is not solved by UDP/HTTP.

Well http is a short lived request/response.

Sockets need keep alives and resources allocated et al.

Re: Websocketd

#147

Post by sureaboutthis »

jchw wrote: post #26

This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.

This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.

Re: Websocketd

#148

Post by aasasd »

sureaboutthis wrote: post #147
jchw wrote: post #26

This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.

This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.

You can also just serve HTTP.

Re: Websocketd

#149

Post by slavik81 »

FullyFunctional wrote: post #38

It looked simple enough, but I was curious about the threading example on https://github.com/joewalnes/websocketd/wiki/CPP-Input-Outpu... The variable `count` appears to be incremented non-atomically from two different threads. Is that safe in C++?

The second example is also leaking memory.

Re: Websocketd

#150

Post by sureaboutthis »

aasasd wrote: post #148
sureaboutthis wrote: post #147

Earlier quoted context omitted.

This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.

You can also just serve HTTP.

That has nothing to do with my question. Of course you "serve HTTP". I want to know how one interfaces with a server without CGI or fastCGI.
Post reply on HN