Subject: Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
From: Daniel Trebbien (dtrebbien_at_[hidden])
Date: 2010-02-21 19:51:56
From the rationale page of the documentation, it appears that one of the
intended applications of a tokenmap is in the implementation of state
management on top of an otherwise stateless protocol (such as HTTP).
With HTTP, a common trick of tracking state (whether a user is logged in,
their username, etc.) is to set a cookie that contains a session id. The
client stores the session id and the server serializes all state data,
saving it on the server side, and associates this data with that id. For
each subsequent HTTP request by the client, the client sends the session
id to the server, which then finds the serialized data.
The server can not trust anything that the client sends, so the server
needs a way to verify the id. At a minimum, an associative container of
some sort is needed that maps the session id (token) to the serialized
data. To safely use an iterator or a pointer to the inserted element, the
server would need a separate map from tokens to iterators. The tokenmap
solution combines the two maps that would be involved (token to session
data and token to iterator into the other map, with the token-to-iterator
map being extremely fast in performing lookups).
> How is it different from having an iterator or a pointer to the inserted
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk