THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#210 - not null-terminated string in function pipport2su (modules_k/siptrace/siptrace.c)
User who did this - Alexandr Dubovikov (adubovikov)
----------
Hallo Michal,
fixed. Thanks
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d5fbc4e…
Wbr,
Alexandr
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=210#comment513
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#210 - not null-terminated string in function pipport2su (modules_k/siptrace/siptrace.c)
User who did this - Alexandr Dubovikov (adubovikov)
http://sip-router.org/tracker/index.php?do=details&task_id=210
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Module: sip-router
Branch: master
Commit: 201fc2d600e48fbb717531c79013c1b971f82d76
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=201fc2d…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Mar 27 14:38:57 2012 +0200
db_cluster: new module for generic database clustering
- the module allow to group several DB connections and perform commands
over them, based on policies such as round robin, serial try or
parallel execution
- any kind of db connection can make part from a cluster
- example use case: write in parallel to two databases and do round
robin read from them
- the module is a middle layer between modules and databases, reusing
existing db connectors. A module that wants to use such cluster, just
have to set the db_url to "cluster://clusterid"
- the module allow definition of multiple clusters
- see README for more details
- todo: enable/disable connections at runtime and via rpc
---
modules_k/db_cluster/Makefile | 15 +
modules_k/db_cluster/README | 162 +++++++++
modules_k/db_cluster/db_cluster_mod.c | 112 ++++++
modules_k/db_cluster/dbcl_api.c | 437 ++++++++++++++++++++++
modules_k/db_cluster/dbcl_api.h | 142 ++++++++
modules_k/db_cluster/dbcl_data.c | 479 +++++++++++++++++++++++++
modules_k/db_cluster/dbcl_data.h | 89 +++++
modules_k/db_cluster/doc/Makefile | 4 +
modules_k/db_cluster/doc/db_cluster.xml | 37 ++
modules_k/db_cluster/doc/db_cluster_admin.xml | 167 +++++++++
10 files changed, 1644 insertions(+), 0 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=201…
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#210 - not null-terminated string in function pipport2su (modules_k/siptrace/siptrace.c)
User who did this - Michal Karas (Largon)
http://sip-router.org/tracker/index.php?do=details&task_id=210
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Michal Karas (Largon)
Attached to Project - sip-router
Summary - not null-terminated string in function pipport2su (modules_k/siptrace/siptrace.c)
Task Type - Bug Report
Category - Modules kamailio
Status - Assigned
Assigned To - Daniel-Constantin Mierla
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - Hello,
we encountered bug causing some packets to be ignored because of not null-terminated string in function pipport2su.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=210
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi,
RFC 3856 section 6.10 states: "A PA SHOULD NOT generate notifications for
a single presentity at a rate of more than once every five seconds."
I would like to add this to the presence module (making the rate
configurable).
I have an idea as to how I would like to do it:
- Add a last notified time-stamp field to each presentity
- Add a updated since last notified flag field to each presentity
- Add a notify required flag field to each active_watcher
- When a presentity is updated the last notified time-stamp is checked.
If the time is far enough in the past the notifies are sent and the
time-stamp is updated. If enough time has not passed the updated since
flag is set for the presentity and the notify required flag is set for all
active_watchers of that presentity.
- When a presentity is subscribed to (this includes re-subscribes) the
last notified time-stamp is checked. If the time is far enough in the
past the (single) notify is sent and the time-stamp is updated. If enough
time has not passed the updated since flag is set for the presentity and
the notify required flag is set for this active_watcher record.
- A timer (the minimum time between subscribes - default 5 seconds) is
run. On expiry a query is done on the presentity table for presentities
that have been updated _AND_ the last notified time is more than the
minimum time ago. For each of these presentities, a query is done on the
active_watchers for watchers of that presentity that have the notify
required flag set. Notifies containing the presentities are then sent to
the watchers waiting on them.
This should ensure that no presentity notifies more than it should, while
ensuring that all changes are (eventually) sent out, and all subscribes
result in a notify (eventually) being sent. Eventually being typically
within 5 seconds and in under 10 seconds in the worst case (assuming the
default setting of 5 seconds).
Can anyone see any problems with this?
Are there any objections to me implementing this?
In theory running a (5 second) timer could make presence "lumpy" in the
same way RLS is (see my previous email). However, if this proves to be
the case I believe the same mechanism I have proposed for RLS can be used
here.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd