4 ms·
I don't think that's disingenuous. It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture. We
by ikawe 13y ago
I don't think that's disingenuous.
It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture.
We can also assume people are running this software on multiprocessing machines with connections to the internet.
Of course there's always people "doing it wrong," but caveating every potential misunderstanding is a slow way to communicate.
edit: Your post is still valuable though! Thanks for highlighting what makes these frameworks sensible for use with websockets.
- timr 13y ago"It's safe to assume that anyone who hopes to leverage websockets will not be using a blocking application architecture." No, it isn't. I'll wager that right this very second, there's someone out there incorporating websockets into their Heroku-based Rails app and not thinking about (or understanding) the consequences.
- wmf 13y agoWouldn't such an app be hosed on almost any platform due to massive memory waste?
- gnur 13y agoI don't think the memory waste is the problem in this case, a websocket is a long lived connection. If you mix it with regular requests and don't think about the concurrency consequences you'll be able to serve 1 request and then allow for 1 websocket connection and your done. All other connections will be pending until the websocket is closed.