Re: HTTP router point-of-view concerns

On Sat, Jul 13, 2013 at 05:29:59AM +1200, Amos Jeffries wrote:
> In these cases you build your session identifier to contain a shard 
> reference as well as an UID.
> For example I'm pretty sure that Facebook does not replicate all users 
> entire account details onto each and every server, or in a Cookie being 
> sent back and forward. For good reason. No, they have an ID which allows 
> extremely fast backend referencing for whatever assembly server is 
> running to access whatever data server the users account it stored on. 
> Not exactly complex even when running at large scale.
> 
> 
> >So there *is* some use to store data on the client, it's just that it
> >has been long abused to store session identifiers because it was the
> >only mechanism available.
> 
> Only the Session ID and/or a shard reference (combined in one opaque 
> blob is even better) need be stored on the client.

A shard reference or session ID are two completely different things. A
session ID comes from one referential. A shard reference indicates what
referential to use. That's why a user-provided session ID cannot be used
as a shard reference and prevents from scaling. I *do* use cookies exactly
as you describe because it's the only way to scale, and have been doing so
for almost a decade now. In a cookie, you can indicate the DC, the server,
a location in a database, etc... Whatever you need to perform very fast
access. You simply can't do that by learning massive amounts of randoms
generated by clients.

Regards,
Willy

Received on Friday, 12 July 2013 20:02:59 UTC