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

Poll: Unknown or expired link on YC

news.ycombinator.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Poll: Unknown or expired link on YC

#31

Post by jcl »

lst wrote: post #27

And no one ever tells us the drawbacks of continuations... (Why is this so?)

These error messages are a consequence of any scheme that stores session state on the server: the session data must expire, or the server will fill up. The problem would remain even if some other method of serialization was used instead of continuations.

That said, I expect that continuations store more data than a hand-tuned serialization and thus need to be expired earlier. I'd be curious to know how much more space is used storing continuations versus the bare minimum.

Re: Poll: Unknown or expired link on YC

#32

Post by ralph »

Continuations used to be used more on news.yc but it was trivial to flush the cache by making a few requests from a single client causing everyone's sessions to be hosed. That causes a switch to URL parameters for lots of things; why not all things? It's a fundamentally flawed model that I've never seen pg defend. It's certainly not scalable. Either the server stores info for all N clients, which fails for large N, or you give each client their own piece of info to store.

Re: Poll: Unknown or expired link on YC

#33

Post by ralph »

ralph wrote: post #32

Continuations used to be used more on news.yc but it was trivial to flush the cache by making a few requests from a single client causing everyone's sessions to be hosed. That causes a switch to URL parameters for lots of things; why not all things? It's a fundamentally flawed model that I've never seen pg defend. It's certainly not scalable. Either the server stores info for all N clients, which fails for large N, o…

Let's take http://news.ycombinator.com/threads?id=pg as an example. When I visit that I get dealt 75 fnids. They're different every time I go to the page. So I'm using a new 75 slots in the cache every time. It's little overhead in CPU or bandwidth for me to get the page but it has a big impact on the other users of the system if I flush their fnids out of the cache before they try and use them. I first pointed this out at the end of April 2007. In response, pg cut the number of fnids used, but they've crept back in.

The technique's flawed, trivial to exploit, and should be dumped.

Re: Poll: Unknown or expired link on YC

#34

Post by LogicHoleFlaw »

jcl wrote: post #31
lst wrote: post #27

And no one ever tells us the drawbacks of continuations... (Why is this so?)

These error messages are a consequence of any scheme that stores session state on the server: the session data must expire, or the server will fill up. The problem would remain even if some other method of serialization was used instead of continuations. That said, I expect that continuations store more data than a hand-tuned serialization and thus need to be expired earlier. I'd be curious to know how much more spac…

Some sort of stateless method of interacting with a site helps alleviate the session problem. That's one of the touted advantages of REST architecture.

Re: Poll: Unknown or expired link on YC

#35

Post by jcl »

rsheridan6 wrote: post #14
andreyf wrote: post #7

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacceptable. Are there elegant solutions to fix this? Could someone link the explanation to how the continuation sessions work, please?

Explanation: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www... A possible elegant solution is suggested in the paper: store the continuation on the client. I don't know what problems this presents in practice.

I would imagine that serializing your server's execution state to the client would require some pretty careful sandboxing to avoid security problems.

Re: Poll: Unknown or expired link on YC

#36

Post by vthakr »

cousin_it wrote: post #26

Voted for #1. Maybe a heretical opinion, but why use continuations here at all? Their drawbacks aren't worth it in a simple app like news.yc. Use URL parameters, like /news?skip=30 for paging. Make the "reply" link lead to /item?id=12345 , it already has a reply box. In my own apps I give a lot of thought to URL design. And yeah, don't explain, I do know about closure/cont-based web frameworks - used to be a contribu…

I can totally agree with you here cousin_it. I've noticed this problem a few times on the main user-facing [more] link at the bottom of the news listings and I don't see any reason for it. From what I've seen/read/advocated it's best to use continuations for the backend things such as the admin pages, but keep all of the forward-facing pages as continuations-free as possible in order to avoid just these types of problems. As a user of the site, I should be able to bookmark any page I desire and return to find it still exists rather than the continuation has timed out and I lost a list of really great articles that I was hoping to read.

Re: Poll: Unknown or expired link on YC

#37

Post by ralph »

ralph wrote: post #33
ralph wrote: post #32

Continuations used to be used more on news.yc but it was trivial to flush the cache by making a few requests from a single client causing everyone's sessions to be hosed. That causes a switch to URL parameters for lots of things; why not all things? It's a fundamentally flawed model that I've never seen pg defend. It's certainly not scalable. Either the server stores info for all N clients, which fails for large N, o…

Let's take http://news.ycombinator.com/threads?id=pg as an example. When I visit that I get dealt 75 fnids. They're different every time I go to the page. So I'm using a new 75 slots in the cache every time. It's little overhead in CPU or bandwidth for me to get the page but it has a big impact on the other users of the system if I flush their fnids out of the cache before they try and use them. I first pointed this…

Here's the last time I pointed it out. http://news.ycombinator.com/item?id=18083 pg made the post dead and emailed me about publishing a DDoS. Yet here we still are, using a broken concept.
Post reply on HN