27 Aug
2013
27 Aug
'13
1:10 p.m.
On 08/27/2013 11:57 AM, Daniel-Constantin Mierla wrote:
Hello,
thanks for the patch. Some remarks.
As you highlighted that the solution is not very efficient (due to no
direct mapping between records and tcp connection), it should have a
way to disable it (maybe via mod param for usrloc).
At this moment is hardcoded for 'location' table, but there can be
other names used, since this value is given as parameter to
save()/lookup(). It will have to iterate through all usrloc tables
(called domains interanlly in the module).
Ok, I'll remove hardcoded
"location" domain. It will search in all
domains from dlist_t. Module parameter will be added too.
I understand that search through the all contacts is not for production
use at all. I really need this feature and I'm sure everyone who uses
tcp/tls/ws too so I wanted to start this discussion from a little peace
of code to get feedback from community.
Also, if I didn't get it wrong, it works only with
in-memory records,
if the usrloc is configured in db-only mode, it does not work with
current patch, right?
To remove old contacts i've used delete_ucontact from usrloc api. This
function checks db_mode and removes contact from db in case of DB_ONLY
mode and just updates expiration in case of WRITE_BACK.
I had in mind to implement such features, but using
timer, to iterate
through tcp connections and see if there is still an open connection
for it. This will do delayed discovery, but I am not sure it will
bring more benefits -- initially I thought is faster lookup done by a
dedicated timer, presumly there are less tcp connections that usrloc
records.
Anyhow, perhaps we should do some optimization here,
we can store the
connection id in usrloc structure and then match received address only
if there is same conenction id. Or add received built from tcp
connection close callback in a list that is used by usrloc expires timers.
Searching through a single list from a separate process sounds much
better than my version. I'll try to implement this when I have free time.
The way Olle proposed looks more preferable as it can work in
environment with separate registrar and outbound servers. But I have to
read some theory about outbound before moving this way.