[sr-dev] dispatcher sending socket

Daniel-Constantin Mierla miconda at gmail.com
Wed Nov 12 11:55:19 CET 2014


Hello,

overall, the patch can be committed.

As a remark, printing the socket pointer to a string in an avp and
getting it back is the ideal, still can be a bit faster than storing the
socket string.

For the near future, I think that the dispatcher needs a bit of a review
and move those avps in xavp, where a pointer can be stored directly,
along with other simplifications/optimizations -- but this when the time
comes for it.

Cheers,
Daniel

On 02/11/14 09:25, Federico Cabiddu wrote:
> Hi,
> according to Daniel's suggestion here are my proposed changes to
> implement per gateway and default sending socket in the dispatcher module.
> Some notes about them:
> - per gateway socket configuration is done using the "socket" attribute
> - module default sending socket is configured via the
> "ds_default_socket" parameter
> - sock_avp AVP is used to hold the sockets list for the selected
> gateways. It actually holds a pointer to the socket_info struct for
> the gateway sending socket (I borrowed the idea from another project).
> I'm currently wondering if it makes sense having its name configurable
> and empty by default (I followed the same logic as for the already
> existing AVPs) or if, due to its mainly internal usage, it wouldn't be
> better to give it a name by default and hide it to the module's user. 
>
> Looking forward to hearing your feedback.
>
> Regards,
>
> Federico
>
> On Fri, Oct 31, 2014 at 1:00 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     in the first phase add the socket as an attribute for each gateway.
>
>     At some point we should look at making some of the attributes as
>     dedicated fields (columns), but I would prefer to make it at once
>     for all attributes that should be split out.
>
>     Cheers,
>     Daniel
>
>
>     On 31/10/14 11:37, Federico Cabiddu wrote:
>>     Hi all,
>>     after fighting in the last days with dispatcher and the socket
>>     used to send pings and dispatch requests, I'm thinking in adding
>>     to the module the support for configuring the sending socket.
>>     Specifically what I'm thinking is:
>>
>>     1) add the sending socket as a gateways' parameter 
>>     2) add an avp to store the gateways' send socket, to be used for
>>     load balancing failover
>>     3) add a module parameter "ds_send_socket" to define a global socket 
>>
>>     The logic to select the sending socket would be:
>>
>>     1) if the gateway has send socket configured, use it
>>     2) else, if configured, use the socket specified in ds_send_socket
>>     3 else use the socket corresponding to the first listen directive
>>     (current behaviour)
>>
>>     What do you think about? Do you find that this would be generally
>>     useful?
>>     About adding the send socket per gateway: how do you think it
>>     should be configured? In a dedicated column (db or file) or in
>>     the attrs parameter (just adding another attributes)?
>>
>>     Looking forward to your feedback.
>>
>>     Cheers,
>>
>>     Federico
>>
>>
>>
>>     _______________________________________________
>>     sr-dev mailing list
>>     sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>     -- 
>     Daniel-Constantin Mierla
>     http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>
>
>     _______________________________________________
>     sr-dev mailing list
>     sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141112/4eea4dc6/attachment.html>


More information about the sr-dev mailing list