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

41–50 of 233 posts

Re: Websocketd

#41

Post by cat199 »

packetslave wrote: post #12
gok wrote: post #10

Ok I know the software-today-is-so-bloated trope is overplayed but... "the UNIX way"? The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.

SVR4 came out 30 years ago. I think it's time to let it go.

Aah the joys of false progressivism.

I hear that representing the absence of value as a number was invented about 6000 years ago, perhaps we should abandon that as antiquated as well..

also, to wit, a Unix kernel of recent vintage:

    $ uname -msr
    OpenBSD 6.3 amd64
    $ du -skc bsd.rd bsd  
    9664    bsd.rd
    12912   bsd
    22576   total
vs, say, a Linux kernel of recent vintage:

    $ uname -msr
    Linux 4.9.0-8-amd64 x86_64
    $ du -skc /boot/vmlinuz-4.9.0-8-amd64 /boot/initrd.img-4.9.0-8-amd64 /lib/modules/4.9.0-8-amd64
    4152	/boot/vmlinuz-4.9.0-8-amd64
    21616	/boot/initrd.img-4.9.0-8-amd64
    212248	/lib/modules/4.9.0-8-amd64
    238016	total
yes, there are likely more drivers in the latter. highly doubt there is an order of magnitude more though.

not to mention some 'modern' npm+webpack monstrosity.

that said, given the latter, i can hardly fault a <10Mb go executable as 'excessive', so you're right on that front.

Re: Websocketd

#42

Post by arama471 »

xrobledo84 wrote: post #40

Or just use cowboy which is written is in erlang and will scale better.

Is there any other benefit than scaling better? Because I'm pretty sure 99.9% of projects never hit the "need to scale more" part, and if they did it doesn't seem like this would be too difficult to move off of

Re: Websocketd

#43

Post by yjftsjthsd-h »

jchook wrote: post #32
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.

Is that a feature or a bug of *nix?

Not really; IIRC forking is more expensive on NT, and *nix processes/threads tend to be fairly cheap. It might be a generally expensive model, and threads/pools are probably the better-scaling option regardless of OS.

Re: Websocketd

#44

Post by ignoramous »

ape4 wrote: post #35
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.

But websocket connections are usually long lasting. So the cost of the fork is less important.

I think it all boils down to how much can it scale. At what point do # of processes tip over a server versus how many # of threads can it handle versus how many # green threads a program runtime can manage.

Re: Websocketd

#45

Post by blitmap »

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.

I really enjoyed SCGI in Lua:

https://github.com/blitmap/lua-snippets/blob/master/scgi-ser...

Re: Websocketd

#46

Post by xyzzy123 »

Matthias247 wrote: post #39

Doesn’t this have an impedance mismatch? Stdin/out are stream based. Websocket is message based. There is no guarantee you can transmit the content of a single WebSocket message inside a single os read or write call. Unless you expect that on both sides messages might be fragmented across multiple calls and callbacks. But I don’t see the docs mentioning that.

Interested to know in what situations you anticipate this would cause problems?

Re: Websocketd

#47

Post by baybal2 »

>Avoid threading headaches

>Each inbound WebSocket connection runs your program in a dedicated process.

Not the best design decision

Re: Websocketd

#48

Post by [deleted] »

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++?

[deleted]

Re: Websocketd

#49

Post by verroq »

xyzzy123 wrote: post #46
Matthias247 wrote: post #39

Doesn’t this have an impedance mismatch? Stdin/out are stream based. Websocket is message based. There is no guarantee you can transmit the content of a single WebSocket message inside a single os read or write call. Unless you expect that on both sides messages might be fragmented across multiple calls and callbacks. But I don’t see the docs mentioning that.

Interested to know in what situations you anticipate this would cause problems?

In every situation? The API interface doesn’t match.

Websocket isn’t a stream, it is framed. Obviously it can be used like a stream but that depends on the client and server. The issue here is that all the client side (browser) APIs expose frames instead of streams.

Suppose I send a JSON object I have no idea what framing this socket server will use and if it’ll break it up into multiple pieces and require the client to reassemble it. If I send two JSON objects in a row does it arrive in two websocket frames or could it buffered into one?

Secondly the websocket protocol is much more complex than a tcp stream. It has keep alive packets that can be sent, it has close packets that allow a connection to terminate with a given code that can be handled by the client. How are these exposed?

Re: Websocketd

#50

Post by jampekka »

Matthias247 wrote: post #39

Doesn’t this have an impedance mismatch? Stdin/out are stream based. Websocket is message based. There is no guarantee you can transmit the content of a single WebSocket message inside a single os read or write call. Unless you expect that on both sides messages might be fragmented across multiple calls and callbacks. But I don’t see the docs mentioning that.

It's line based. A newline character separates messages.

https://github.com/joewalnes/websocketd/wiki/Ten-minute-tuto...

Post reply on HN