Changes between Version 1 and Version 2 of doc/developer/TokenArchitecture

Show
Ignore:
Timestamp:
05/01/07 18:28:23 (15 years ago)
Author:
benoitg
Comment:

Update (work in progress)

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/TokenArchitecture

    v1 v2  
    11[[PageOutline]] 
    2 Original author: Benoit Grégoire, last modified: 2007-01-05 
     2Contributor(s): Benoit Grégoire, last modified: 2007-05-01 
     3 
    34= Token, General model = 
    4 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: 
     5Currently, 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 foot, 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 (such as selling pre-paid time). 
     6 
     7 
     8What follows is a first draft at doing so. 
     9 
    510== Data model == 
    611tokens 
    712 * token_id 
    813 * token_status 
    9  * max_data_transfer Ex: Allows capping bandwidth 
    10  * max_connection_duration: Ex: Allows limiting the length of a single connection 
    11  * max_total_duration: Ex: Allows selling access by the hour 
    12  * expiration_date: Ex:  Allows selling weekly or monthly passes 
     14 * token_network (Note:  Server-wide tokens aren't supported, but the code will look up the tokens of networks you peer with) 
     15 * token_max_data_transfer Ex: Allows capping bandwidth 
     16 * token_max_connection_duration: Ex: Allows limiting the length of a single connection 
     17 * token_max_total_duration: Ex: Allows selling access by the hour 
     18 * token_expiration_date: Ex:  Allows selling daily, weekly or monthly passes 
    1319 * is_reusable:  Is the connection reusable? (normally, yes) 
    14 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.  
     20 
     21tokens_valid_nodes (Unfortunately, for hotels selling 24h access to their clients, we have to consider that their network may consist of more than one node.  If the token has no entry in this table, it's considered valid everywhere on the Network (and it's peers)) 
     22 * token_id 
     23 * token_valid_at_node 
     24 
     25When a connection is established, the values in the tokens table are used, along with eventual network policies (maximum 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.  
    1526 
    1627connection (new or redefined field in existing table) 
    1728 * token_id Now references the tokens table 
    18  * max_data_transfer  
    19  * expiration_date 
     29 * max_data_transfer   (token_max_data_transfer - SUM(data transfer for all connections on this token)) 
     30 * expiration_date (MIN(NOW+token_max_connection_duration, NOW+token_max_total_duration-SUM(data transfer for all connections on this token), token_expiration_date)) 
    2031