Version 1 (modified by benoitg, 14 years ago)

Future token architecture

Original author: Benoit Grégoire, last modified: 2007-01-05

Token, General model

Currently, connection tokens are very weak entities, directly stored in the connection table. Many stakeholders would like to add features to connections (time limit, persistent token, etc.) to support the different WirelessCommunityModels. To do this without shooting ourselves in the foor, we need a data model that can solve the general problem of connection handling and re-use, not just a specific degenerate case of it. What follows is a first draft at doing so:

Data model


  • token_id
  • token_status
  • max_data_transfer Ex: Allows capping bandwidth
  • max_connection_duration: Ex: Allows limiting the length of a single connection
  • max_total_duration: Ex: Allows selling access by the hour
  • expiration_date: Ex: Allows selling weekly or monthly passes
  • is_reusable: Is the connection reusable? (normally, yes)

When a connection is established, the values in the tokens table are used, along with eventual network policies (maimum monthly data transfer, maximum connection time) or node policies (opening hours) to calculate max_data_transfer and expiration_date in the connection table. This calculation is expensive, but once done, all the auth server has to do is validate max_data_transfer and expiration_date which is practically free.

connection (new or redefined field in existing table)

  • token_id Now references the tokens table
  • max_data_transfer
  • expiration_date