2010/5/30 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
This is, just gws 1 and 2 are loaded in gw_uri_avp (or sometimes gws 1 and 3). Note that gws 2 and 3 have same IP but *different* port, so there is no reason at all not to load gw 3.
IMHO this shouldn't be the behavior, in fact it seems buggy IMHO. I know that same occurs in 3.0 version. Any comment?
inaki,
the comment is that currently uniqueness of gws is based only on gw's ip address or hostname , i.e., port is not considered. after quick look at the code, it should be quite easy to add checking of port too.
SInce different gws can exist in gw table with same ip:[port] but different attributes (strip, flags, etc) I think it should be possible to load gateways with same ip[:port] for same request if theses gateways match the rules.
BTW I strongly think that LCR module should be improved and I would like to do it. Some ideas I have in mind:
- Improve the tables design by having three tables: lcr_rules,
lcr_groups and lcr_gws.
i cannot comment on this one unless you tell why three tables are needed.
Main reason: current design makes *very* difficult to manage the tables content via an admin interface (i.e. a web interface). Also, if I want to include same gateway (so same IP, port and attributes) in two rules then I must to repeat same data in two different gw entries. This is not good from a design point of view.
What I'll propose is:
- table 'lcr_rules' (same as 'lcr') includes entries with 'instance_id', 'grp_id' and so. Also it would contain two new columns: 'enabled' (the rule is just loaded if it's 1), and 'stop' (no new rules are inspected when 'load_gws()' finds this rule). More about this at the end of the mail. Also I would add a new schema constain: a composite UNIQUE key for columns 'prefix', 'grp_id' and 'priority' as it makes no sense two rules with same prefix, grp_id and priority (which is chosen first? is it random?).
- table 'lcr_gws' include gateways definition. Same as current 'gw' table but *without* 'grp_id' and 'instance_id' columns.
- table 'lcr_groups' contains these columns: - id: primary key as usual. - grp_id: The group identifier. - gw_id: integer pointing to the id column of an entry under 'lcr_gws' table.º If a group contains 2 gateways then two entries would exist in this table with same 'grp_id', each one with 'gw_id' pointing to the corresponding entry under 'lcr_gws' table.
This would make management of lcr easier as it respects some basic design patterns: - Each lcr rule contains some attributes (priority, prefix...) and "belongs to" one gws group (grp_id). - Each gws group "has many" gateways (entries under lcr_gws table) and also "has_many" lcr rules (as same grp_id could appear in different lcr_rules entries). - Each gateway must be defined just *once* even if it used by various lcr groups (different gws groups sharing the same gateway without having to duplicate its information ini two places, why not?).
- An option to enable/dissable a gw (by setting a 0 in a new "enabled"
- column).
that already exists in 3.0 (see defunct column).
ok :)
- Am option to allow stopping lcr_rules, this is, if the lcr_rule is
choosen (by priority/prefix/from_uri) and the request fails, no other gateways from other lcr_rules would be tryed.
why can't you do this in the script?
Because it's ugly to do so in the script, it makes unfeasible to admin it via a web interface. A common use case: - I want a default route using gw1 and gw2 (for any prefix). - In calls to 001 (USA) I want to use *just* gw3, so I could create a lcr rule with prefix 001 and grp_id=X, and a lcr_group with id=X containing just gw3. - If gw3 is down or replies 503 (this is, if the USA lcr rule fails) I don't want to try the default route (gw1 and gw2). This is not possible with the current design as the default route (lcr rules with no prefix) would be loaded automatically. - With my proposal (a column "stop" with value 1) there is no need to coding ugly and static code in failure_route. Instead load_gws() would stop inspecting lcr_rules table when a rule with "stop=1" is found.
I suggest/propose all of this due to my real experience. I've deployed a proxy for load balancing, failover and routing (based on prefix) to some PSTN gateways and after implementing it I really miss the above features.
Regards.
PS: I'll write such specifications and proposals somewhere (maybe in the wiki) and will share here to comment.