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
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
On 29/02/16 01:37, Juha Heinanen wrote:
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.
there is already a connection_id in the database table location? Or do you mean something else?
Cheers, Daniel
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
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?
Yes, but no index on it. Without an index, it may take a long time to delete a record based on connection_id.
-- Juha
On 29/02/16 09:21, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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?
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 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
On 01/03/16 08:59, Juha Heinanen wrote:
Juha Heinanen writes:
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?
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
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
-
Daniel-Constantin Mierla -
Juha Heinanen