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.