16 ms·
Websocketd
- loeg 8y agoSo, all of the same sorts of scaling problems as inetd?
- dpwm 8y agoWell, unless it's doing something exceedingly clever, it looks like it will be launching one process per connection. For communication servers, this could prove a challenge – you'll probably want to use some kind of pub-sub architecture. By the time you've gone down that road, you could've gone down one of the more robust paths. Still, this looks great for smaller apps. And, it seems a great way to prototype – especially if your favourite language doesn't have great websocket support.
- loeg 8y ago> Still, this looks great for smaller apps. And, it seems a great way to prototype – especially if your favourite language doesn't have great websocket support. Totally agree. inetd is a pretty good model, it just falls down in the face of thousands of slow, low-computational effort connections tying up gigabytes of RAM. That and most schedulers seem to struggle with that number of threads.
- iknowstuff 8y agoHow do posts like this end up at #2 on the front page with just one comment? Websocketd doesn't strike me as an particularly popular or well known tool.
- thinkingkong 8y agoI think the velocity of the votes and the unique-ness of their geography matters a lot more than comments or discussions.
- mehrdadn 8y ago> unique-ness of their geography The location of the server is a factor??
- dc_gregory 8y agoThe location of the voter.
- mehrdadn 8y agoOhh I see, okay thanks. Surprising but cool!
- viraptor 8y agoIt's not listed in https://github.com/minimaxir/hacker-news-undocumented/blob/master/README.md https://github.com/minimaxir/hacker-news-undocumented/blob/m... or in https://drewdevault.com/2017/09/13/Analyzing-HN.html https://drewdevault.com/2017/09/13/Analyzing-HN.html It's the first time I hear anyone mention it. It would be great if OP had some supporting link.
- chrisseaton 8y agoWell if it was popular or well known why would it be news-worthy?
- tomhoward 8y agoIndeed. Discovering interesting new things is one of the main purposes of HN.
- joefourier 8y agoI'd be interested to know if anybody has used this in production. I've used Websocketd for quick and dirty prototyping and making things like in-browser monitoring tools and it was very fast to setup, but a full-fledged library like Gorilla or uWebsockets seems more practical for real-world applications with thousands or more simultaneous users.
- mholt 8y agoWebsocketd is neat. It inspired me to make the websocket directive in Caddy: https://caddyserver.com/docs/websocket https://caddyserver.com/docs/websocket
- PixyMisa 8y agoAha! My first thought was "Why use this instead of Caddy's websocket support?" Answer: Websocketd came first.
- kccqzy 8y agoSo kind of like CGI. Okay.
- pdxandi 8y agoThat's what they say on their site: "It's like CGI, twenty years later, for WebSockets"
- bwasti 8y agoReminds me of a little project I did a while back, but instead reading from stdin like netcat https://github.com/bwasti/webpipe https://github.com/bwasti/webpipe
- gok 8y agoOk 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.
- packetslave 8y agoSVR4 came out 30 years ago. I think it's time to let it go.
- gok 8y agoI'm fine with letting it go! I just don't understand why they're claiming this is "the UNIX way" as if that's a good thing.
- thaumaturgy 8y agoI hate to be trollbait, but: "the Unix way" is less about the size of programs, and more about programs being built as composable, modular components that interact together over a common interface. Curious people can read more about it at https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy or https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s... The websocketd site outlines this fairly well with the big quote on their homepage. Looked at another way, a Unix-like ecosystem satisfies two of the principles of a SOLID software architecture: the Single Responsibility Principle and (arguably) the Open-Closed Principle. If websocketd focuses on handling the nuts and bolts of websocket connections and invoking other programs and piping data into and out of them over a standard interface, then it's a Unix-like architecture, even if it's a fat, monolithic, statically linked binary.
- throw2016 8y agoThe unix way is 'decoupled microservices', breaking down components in to small pieces for reuse, it continues to be used and reinvented in different contexts. Both monolith and decoupled components have their cheerleaders but simply dismissing either as 'not a good thing' doesn't add anything to the debate.
- exabrial 8y agoGood time to plug this utility, swiss army knife for websockets: https://github.com/vi/websocat https://github.com/vi/websocat Author is extremely nice as well.
- gruez 8y agois it me, or does the site look really similar to letsencrypt.org? I looked on both sites and neither say they're using a template.
- mushufasa 8y agoFWIW the css template is just some bootstrap stuff, and this for the syntax highlighter in the code snippets: /* http://prismjs.com/download.html?themes=prism-twilight&languages=clike+javascript+bash+c+csharp+go+java+php+python+ruby+swift http://prismjs.com/download.html?themes=prism-twilight&langu... / /* * prism.js Twilight theme * Based (more or less) on the Twilight theme originally of Textmate fame. * @author Remy Bach */
- justinclift 8y agoIf someone really cares to investigate, the Letsencrypt.org website (Hugo based) is here for starting with: https://github.com/letsencrypt/website https://github.com/letsencrypt/website
- xmichael999 8y agoCould this then be used to replace node and this type of mess? https://github.com/phoboslab/jsmpeg/blob/master/websocket-relay.js https://github.com/phoboslab/jsmpeg/blob/master/websocket-re...
- bazza451 8y agoCode looks reasonable.....
- jchw 8y agoThis 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.
- jchook 8y agoIs that a feature or a bug of *nix?
- yjftsjthsd-h 8y agoNot 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.
- jchw 8y agoOn NT though, there's a deeper divide between processes and threads. Threads on NT should be a lot cheaper. Especially since you can't fork on NT without diving into undocumented APIs* :) *On the Windows subsystem, of course. There's the lower level ZwCreateProcess function which can/could be used to fork, but it's undocumented and I believe it only existed for the old SfU. Now that that's gone and Linux Subsystem uses something called Pico Processes, I'm guessing this old fork flag is pretty much unsafe to use for anything at all.
- ape4 8y agoBut websocket connections are usually long lasting. So the cost of the fork is less important.
- ignoramous 8y agoI 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.
- rileytg 8y agoi’ve been using this in production to stream logs to a web console (~2,000 sets of logs distributed across 4 server with about 350 active connections at a time) and have never had any issues
- hnarn 8y agoHow do you know that you haven't had any issues?
- perlgeek 8y agoUsually you notice issues by the server locking up, the clients reporting problems, or messages being missing from the log (which you tend to notice when you search for specific things in the logs).
- hnarn 8y agoSo how do you know that you're not just getting 80% of "log entry X" just because you get hits for them every now and then?
- perlgeek 8y agoLogging is usually pretty deterministic. A request might generate log entries a, b1, c or a, b2, c, depending on some conditions. The exact contents vary by request (otherwise there would be no need to log them), but the type is always the same. If you find logs for c without either b1/b2 or a, you know log entries went missing. If you have a 20% miss rate with recording your log entries, and you analyze just 20 log entries, the chance that one of them is missing is already around 98.8%. If you actually use your logs for anything, it becomes pretty obvious pretty quickly when they are incomplete.
- rileytg 8y agowe track errors both server and client side. only errors we routinely see are network issues.
- jchook 8y agoIf you really wanted to follow UNIX philosophy, why not build atop xinetd? for example... simply accept stdin and stdout as I/O streams by default, but don't provide a network mechanism.
- masklinn 8y agoYou can put websocketd behind xinetd. xinetd doesn't talk websocket, so you still need to "provide a network mechanism" to bridge the incoming connection and the client's streams.
- cogburnd02 8y ago> xinetd doesn't talk websocket Why not extend xinetd so that it can interact with websockets?
- masklinn 8y agoBecause the point of xinetd is to spawn other daemons on socket activations. xinetd handling stuff itself is the exception not the rule (5 service are internally provided, none of which you want to run: RFC 862 "echo", RFC 863 "Discard", RFC 864 "CHARGEN", RFC 867 "daytime" and RFC 868 "time").
- bhargav 8y agoWondering if it would be more "unixy" to use sock files [1] ? I think some WSGI servers such as Gunicorn [2] support said functionality. I do think there is a place for websocketd provided you do not use tools like WSGI servers already. 1: https://en.wikipedia.org/wiki/Unix_domain_socket https://en.wikipedia.org/wiki/Unix_domain_socket 2: http://docs.gunicorn.org/en/stable/deploy.html?highlight=sock http://docs.gunicorn.org/en/stable/deploy.html?highlight=soc...
- FullyFunctional 8y agoIt looked simple enough, but I was curious about the threading example on https://github.com/joewalnes/websocketd/wiki/CPP-Input-Output-Example 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 8y ago[deleted]
- comex 8y agoIt is unsafe. But it would be safe if these two lines were swapped: count++; pthread_mutex_lock(&m); since the reader already holds the mutex while reading `count`.
- justinclift 8y agoDo a PR or equivalent?
- saagarjha 8y agoFriendly reminder that not everyone is in a position where they can create pull requests against random projects: they might not have time, or clearance from their company's legal department, or…
- justinclift 8y ago??? Note it was a question. As you mention, not everyone can do so (etc).
- saagarjha 8y agoThe question looked like "why are aren't you making a PR for this".
- slavik81 8y ago
- Matthias247 8y agoDoesn’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.
- xyzzy123 8y agoInterested to know in what situations you anticipate this would cause problems?
- verroq 8y agoIn 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?
- Matthias247 8y agoI estimated that the daemon just tried to send the data from the local application as a websocket messages whenever it received something through the FD. If the application tries to write a 100kB message to stdout, the daemon might pull this out in smaller chunks of it's socket, since the OS buffer might be not as big. If it's 50kB, then the daemon would send 2 50kB messages instead of a single 100kB one. If the JS on the other side would have estimated that everything is inside a single message things would be broken. However it looks like the Daemon might wait for a newline until it forwards everything as a message. Which at least fixes this problem, but might have other side effects.
- xrobledo84 8y agoOr just use cowboy which is written is in erlang and will scale better.
- arama471 8y agoIs 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
- baybal2 8y ago>Avoid threading headaches >Each inbound WebSocket connection runs your program in a dedicated process. Not the best design decision
- icebraining 8y agoThe quality of the design depends on the goals. For simplicity, seems like a great decision.
- ziont 8y agoCGI 20 years later? can somebody explain what they mean by this edit: okay this is pretty cool, what use cases is there?
- iAm25626 8y agoSeems useful! Remind me of pushpin.
- wahjiwah 8y agoThis 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.
- wahjiwah 8y agoBut websocket connections are usually long lasting. So the cost of the fork is less important.
- jasonhansel 8y agoUnpopular opinion: AWS lambda is basically equivalent to CGI. The web has come full circle.
- deleted 8y ago[deleted]
- justinclift 8y agoSeveral times. :D
- icebraining 8y agoIt's closer to FCGI, since Lambda processes aren't restarted for each new request.
- jasonhansel 8y agoQuestion: why doesn't Amazon just use the standard FCGI interface, then?
- icebraining 8y agoMaybe they are; as far as I know, the protocol they use to communicate with the worker isn't specified, all they say is "implement a function with this signature, then import our SDK, and it will call your function". This gives them the flexibility to switch protocols at will, at the cost of having to implement these SDKs. That said, building a FCGI "bridge" isn't hard, it's just that nobody cared enough to do it.
- karl_p 8y agoThey have specified the lambda runtime. https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.ht... Basically: your instance POSTS to an endpoint to get/reply to requests, one at a time. I can't wait until you can specify that a lambda instance can handle a certain # of requests in parallel. Ex: things just blocked on IO/DB. That would make better use of your RAM.
- zemo 8y agowhat if you need two clients to connect to the same process
- echofavor 8y agoThanks for sharing. You can also share your ideas for free on www.echofavor.com
- Ericson2314 8y agoThe unix philosophy is massively overrated because processes are unwieldy in practice, and support only weak notions of composition even in theory.
- sefrost 8y agoDoes anyone have any experience using websockets in a serverless architecture?
- lucasverra 8y agoi do, using back4app (parse server) architecture. shoot your question
- weedium 8y agoDepends on what your needs are. <ahref="https://weedium.com/">Read https://weedium.com/">Read more</a>
- Walkman 8y ago> Each inbound WebSocket connection runs your program in a dedicated process. Connections are isolated by process. I see you and 10,900 other "software developers" get the point of WebSocket. It's especially "impressive" when you written the whole thing in Go and could have used goroutines and channels, which could easily handle hundreds of thousand of connections (maybe millions). Terrible design! For a long time I thought every software developer must be smart, but a lot of them don't see the big picture very often. Why this bothers me so much? You created something that a lot of developers think is good enough, so less innovation will happen and more and more slow websites will appear because of tech like this...
- willeh 8y agoThere are definitely use cases for this, for instance you might have some command line application that uses standard io. Sure it might be adapted to have support for web sockets natively, but this of course takes time. And as the old adage goes time is money. And sure you might be upset by "slow" websites, but for the small consultancy productising their scripts, it might make them - dare I say it, a quick buck. In the end the invisible hand of the market decides how much money is invested making websites fast and that is what guides the design of the technology being developed. Perhaps it is you who fail to see the big picture.
- rakoo 8y agoThe business logic is all outside of websocketd. There is no standard as to how to do this, so obviously the simplest way is to mimic CGI. Invocation happens when the status quo isn't enough, and the status quo until now was that there was no 10-second way to send whatever you want through websocket. It can happen now, and you can be the one to propose some better protocol for a websocket endpoint and a business logic process to discuss.
- houseinthewoods 8y agoI've never felt a stronger sense of https://xkcd.com/386/ https://xkcd.com/386/ in my life. Why are you being so cynical? The author made a tool with no interface that turns any program into a websocket server, making no claim that it can directly replace production servers focused on scale. What are you complaining about? Who hurt you?
- minhajuddin 8y agoThis is really useful for building one of utility websites. I used this in one of my previous companies to tail the logs on our little QA server and push them via websocktd to an internal web page.
- ficklepickle 8y agoFYI, the page needs a viewport tag in the head to display properly on mobile: <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
- gadelat 8y agoI've built similar tool, but for HTTP at https://github.com/ostrolucky/stdinho https://github.com/ostrolucky/stdinho