Re: HTTP router point-of-view concerns

[Willy Tarreau <[e-mail]>]

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