28 Feb
2016
28 Feb
'16
11:22 p.m.
I have done some more digging on websocket:closed event route.
In DB_ONLY mode, easy deregistration of a websocket UA at connection
close would require access in the event route to connection_id of the
closed connection.
The function that is run at the close has ws_connection_t argument:
static void wsconn_run_route(ws_connection_t *wsc)
ws_connection_t record has these two fields:
int id; /* id and id_hash are identical to the values */
unsigned id_hash; /* for the corresponding TCP/TLS connection */
Is id the same thing as what is stored in connection_id field of
location table?
If it is, may be its value could be made available to the event route in
a pseudo variable.
-- Juha
29 Feb
29 Feb
2:37 a.m.
Juha Heinanen writes:
If it is, may be its value could be made available to
the event route in
a pseudo variable.
Also, an index on connection_id would need to be created for location
table. Is connection_id unique or can there be duplicates? If unique,
the index could be unique too.
This index is needed also if connection id is stored and hash table.
Can the index still be added? In my opinion, yes, because otherwise
connection_id column is of no use in db only mode.
-- Juha
9:53 a.m.
On 29/02/16 01:37, Juha Heinanen wrote:
Juha Heinanen writes:
there is already a connection_id in the database table location? Or do
you mean something else?
Cheers,
Daniel
If it is, may be its value could be made
available to the event route in
a pseudo variable.
Also, an index on connection_id would need to be created for
location
table. Is connection_id unique or can there be duplicates?
If unique,
the index could be unique too.
This index is needed also if connection id is stored and hash table.
Can the index still be added? In my opinion, yes, because otherwise
connection_id column is of no use in db only mode.
-- Juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com
10:21 a.m.
Daniel-Constantin Mierla writes:
Yes, but no index on it. Without an index, it may take a long time to
delete a record based on connection_id.
-- Juha
Also, an index
on connection_id would need to be created for location
table.
there is already a connection_id in the database table location? Or do
you mean something else?
1:12 p.m.
On 29/02/16 09:21, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Yes, but no index on it. Without an index, it may take a
long time to
delete a record based on connection_id.
ohh, it was apparently too early, I missed the 'index'.
The index can be useful if there is an operation in the config file,
because I think the module doesn't do any match internally only on this
column.
Also, it may be needed to be done in relation with server_id, if the
same location table is shared between different server instances that
use server_id identifiers.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com
Also, an
index on connection_id would need to be created for location
table.
there is already a connection_id in the database table location? Or do
you mean something else?
9:35 p.m.
Daniel-Constantin Mierla writes:
The index can be useful if there is an operation in
the config file,
because I think the module doesn't do any match internally only on this
column.
It is possible to save connection_id to hash table based on source
ip/port and then on connection close add sql_query() call to config that
removes the location table entry.
Also, it may be needed to be done in relation with
server_id, if the
same location table is shared between different server instances that
use server_id identifiers.
So the index would be:
CONSTRAINT connection_idx UNIQUE (`server_id`, `connection_id`)
-- Juha
10:03 a.m.
On 01/03/16 08:59, Juha Heinanen wrote:
Juha Heinanen writes:
I don't think this is needed, the structure is the same and the module
doesn't need the index internally -- practically nothing changes from
module point of view.
When someone is doing sql_query() from config, it may need other indexes
anyhow... it should review each query it is done and optimize as needed.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com
So the index would be:
CONSTRAINT connection_idx UNIQUE (`server_id`, `connection_id`)
I added the index.
Should also version number be updated in case some
people do db upgrades automatically when version changes?
10:02 a.m.
Juha Heinanen writes:
The function that is run at the close has
ws_connection_t argument:
static void wsconn_run_route(ws_connection_t *wsc)
ws_connection_t record has these two fields:
int id; /* id and id_hash are identical to the values */
unsigned id_hash; /* for the corresponding TCP/TLS connection */
Is id the same thing as what is stored in connection_id field of
location table?
I added a syslog message to wsconn_run_route(ws_connection_t *wsc)
function and indeed wsc->id contains the connection_id. I'll assign it
to a pv after master is again available for new stuff.
-- Juha
3188
days inactive
3190
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen