Navigation


Changeset 83:c662d3eb6ff6 in freeDiameter for include/freeDiameter


Ignore:
Timestamp:
Dec 2, 2009 6:28:28 PM (3 years ago)
Author:
Sebastien Decugis <sdecugis@nict.go.jp>
Branch:
default
Message:

Started support for routing module

Location:
include/freeDiameter
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • include/freeDiameter/freeDiameter.h

    r82 r83  
    427427 
    428428/***************************************/ 
     429/*          Routing module             */ 
     430/***************************************/ 
     431 
     432/* This file contains the definitions of types and functions involved in the routing decisions in freeDiameter, 
     433 * and that can be called by extensions.  
     434 * 
     435 * Three different type of messages must be distinguished: 
     436 *  - Messages received, and the peer is final recipient (IN messages) 
     437 *  - Messages received, and the peer is not final recipient (FWD messages) 
     438 *  - Message is locally generated (OUT messages) 
     439 * 
     440 * There are three global message queues (in queues.c) and also peers-specific queues (in struct fd_peer). 
     441 * 
     442 * (*) IN messages processing details: 
     443 *   - the message is received from the remote peer, a FDEVP_CNX_MSG_RECV event is generated for the peer. 
     444 *   - the PSM thread parses the buffer, does some verifications, handles non routable messages (fd_msg_is_routable) 
     445 *   - routable messages are queued in the fd_g_incoming global queue. 
     446 *   - a thread (routing-in) picks the message and takes the decision if it is handled locally or forwarded,  
     447 *       based on local capabilities (registered by extensions). 
     448 *   - If the message is handled locally, it is queued in fd_g_local. 
     449 *   - Another thread (dispatch.c) will handle this message and pass it to registered callbacks (see fd_disp_register in libfreeDiameter.h). 
     450 * 
     451 * (*) FWD messages details: 
     452 *   - The process is the same as for IN messages, until the routing-in threads makes its decision that the message is not handled locally. 
     453 *   - All callbacks registered with fd_rt_fwd_register are called for the message (see bellow). 
     454 *     - these callbacks will typically do proxying work. Note that adding the route-record is handled by the daemon. 
     455 *   - Once all callbacks have been called, the message is queued in the global fd_g_outgoing queue. 
     456 *   - The remaining processing is the same as for OUT messages, as described bellow. 
     457 * 
     458 * (*) OUT messages details: 
     459 *   - The message are picked from fd_g_outgoing, as result of forwarding process or call to fd_msg_send. 
     460 *   - The (routing-out) thread builds a list of possible destinations for the message. 
     461 *     The logic to build this list is as follow: 
     462 *      - create a list of all known peers in the "OPEN" state. 
     463 *      - remove from that list all peers that are in a Route-Record AVP of the message, to avoid routing loops. 
     464 *      - remove also all peers that have previously replied an error message for this message. 
     465 *   - If the list is empty, create an error UNABLE_TO_DELIVER (note: should we trig dynamic discovery here???) and reply this. 
     466 *   - Otherwise, call all callbacks registered by function fd_rt_out_register, with the list of peers and the message. 
     467 *   - Order the resulting list of peers by score (see bellow), and sent the message to the peer with highest (positive) score. 
     468 *    - in case the peer is no longer in the "OPEN" state, send the message to the second peer in the list. 
     469 *      - if no peer is in OPEN state anymore, restart the process of creating the list. 
     470 *   - The peer thread will handle the creation of the Hop-by-hop ID and sending the message. 
     471 * 
     472 * This part of the API (routing-api.h) provides the definitions of the rt_out_cb_t and rt_fwd_cb_t callbacks, and the 
     473 * functions to register and deregister these callbacks. 
     474 */ 
     475 
     476 
     477 
     478/***************************************/ 
    429479/*   Events helpers                    */ 
    430480/***************************************/ 
    431481 
    432 /* Events */ 
    433482struct fd_event { 
    434483        int      code; /* codespace depends on the queue */ 
     
    437486}; 
    438487 
    439 /* Daemon's codespace: 1000->1999 */ 
     488/* Daemon's codespace: 1000->1999 (1500->1999 defined in fD.h) */ 
    440489enum { 
    441490         FDEV_TERMINATE = 1000  /* request to terminate */ 
  • include/freeDiameter/libfreeDiameter.h

    r43 r83  
    16131613 
    16141614/*============================================================*/ 
     1615/*                         ROUTING                            */ 
     1616/*============================================================*/ 
     1617 
     1618/* The following functions are helpers for the routing module.  
     1619  The routing data is stored in the message it-self. */ 
     1620 
     1621/* Structure that contains the routing data for a message */ 
     1622struct rt_data; 
     1623 
     1624/* Following functions are helpers to create the routing data of a message */ 
     1625int  fd_rtd_init(struct rt_data ** rtd); 
     1626void fd_rtd_free(struct rt_data ** rtd); 
     1627 
     1628/* Add a peer to the candidates list */ 
     1629int  fd_rtd_candidate_add(struct rt_data * rtd, char * peerid); 
     1630 
     1631/* Remove a peer from the candidates (if it is found) */ 
     1632void fd_rtd_candidate_del(struct rt_data * rtd, char * peerid, size_t sz /* if !0, peerid does not need to be \0 terminated */); 
     1633 
     1634/* If a peer returned a protocol error for this message, save it so that we don't try to send it there again */ 
     1635int  fd_rtd_error_add(struct rt_data * rtd, char * sentto, uint8_t * origin, size_t originsz, uint32_t rcode); 
     1636 
     1637/* Extract the list of valid candidates, and initialize their scores to 0 */ 
     1638void fd_rtd_candidate_extract(struct rt_data * rtd, struct fd_list ** candidates); 
     1639 
     1640/* The extracted list items have the following structure: */ 
     1641struct rtd_candidate { 
     1642        struct fd_list  chain;  /* link in the list returned by the previous fct */ 
     1643        char *          diamid; /* the diameter Id of the peer */ 
     1644        int             score;  /* the current routing score for this peer, see fd_rt_out_register definition for details */ 
     1645}; 
     1646 
     1647/* Reorder the list of peers */ 
     1648int  fd_rtd_candidate_reorder(struct fd_list * candidates); 
     1649 
     1650 
     1651/*============================================================*/ 
    16151652/*                         MESSAGES                           */ 
    16161653/*============================================================*/ 
     
    19591996 *  EINVAL: a parameter is invalid 
    19601997 */ 
    1961 int fd_msg_rt_associate( struct msg * msg, struct fd_list ** list ); 
    1962 int fd_msg_rt_get      ( struct msg * msg, struct fd_list ** list ); 
     1998int fd_msg_rt_associate( struct msg * msg, struct rt_data ** rtd ); 
     1999int fd_msg_rt_get      ( struct msg * msg, struct rt_data ** rtd ); 
    19632000 
    19642001/* 
Note: See TracChangeset for help on using the changeset viewer.