Iñaki Baz Castillo writes:
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.
yes, i agree that it should be possible to load two gws with the same ip
or hostname if port is not given or if it is given and is different in
the two.
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.
ok.
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.
sounds ok.
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.
does this cover the case where there are two equal priority gw groups
defined for prefix 001?
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.
thanks for your suggestions, it just remains to implement them :-).
-- juha