Hi, I've been playing with SO_REUSEPORT (included in kernel since 3.9) and Kamailio quite successfully. I have a branch for this in my personal fork ( https://github.com/grumvalski/kamailio/tree/tcp_reuseport) that I've been planning to submit as a PR since a while. If you agree I can do it to start the discussion.
Regards, Federico On Wed, Dec 7, 2016 at 9:36 AM, Daniel-Constantin Mierla <mico...@gmail.com> wrote: > Hello, > > I will try to follow up with more on this discussion after I get the > time to check the resources at the links you mentioned. I know that > forcing a source port for a tcp connection was not reliable, but things > may have changed with newer versions of kernels. > > Cheers, > Daniel > > > On 05/12/2016 14:01, Daniel Pocock wrote: > > > > RFC 3261 doesn't appear to require anything more than the default random > > selection of source port for transports like TCP and TLS > > > > Section 18[1] even appears to anticipate that two proxies communicating > > over reliable transports may have two different connections open at the > > same time, one for requests initiated in each direction. > > > > However, I've seen a couple of situations where using the listening port > > as the source port would be beneficial: > > > > - peer has buggy implementation that tries to connect back to source > > port / rport (which should only happen for unreliable transports), > > observed in reSIProcate[2] > > > > - firewall policy is particularly strict and prefers or even expects > > specific source ports to be used > > > > - potentially halves the number of sockets / FDs required (better use of > > system resources) > > > > > > It is not hard to configure a TCP (or TLS) client socket to use a > > specific[3] source port, although as that example[3] demonstrates, there > > could be situations where a socket is not fully closed and a new one > > can't be opened immediately for the same source/dest port combination. > > That type of issue doesn't arise for randomly selected source ports. > > > > > > Has anybody else tried setting a fixed source port for TCP/TLS > > connections and can you share any observations about this for better or > > worse? > > > > Has anybody seen similar behaviour to the bug[2] in other SIP > > implementations? > > > > We are thinking about implementing this as an optional feature in > > reSIProcate, partly to help people mitigate the impact of peers who have > > the bug #137. > > > > Regards, > > > > Daniel > > > > > > 1. https://tools.ietf.org/html/rfc3261#section-18 > > > > 2. https://www.resiprocate.org/bugzilla/show_bug.cgi?id=137 > > > > 3. > > http://stackoverflow.com/questions/2605182/when- > binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reuse > > > > > > > > _______________________________________________ > > sr-dev mailing list > > sr-dev@lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com > > > _______________________________________________ > sr-dev mailing list > sr-dev@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
