Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)

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  
> element?