Use tcp_send_timeout config option also on listening socket to timeout outbound 
messages sent on passive inbound connections.

#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the 
checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING 
guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on 
sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, 
...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook 
files
in `doc/` subfolder, the README file is autogenerated)

#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)

#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the 
checkboxes that apply -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [x] Related to issue #3443

#### Description
Based on the description of core parameter "tcp_send_timeout" the 
timeout should also work for sending on forked incoming tcp connections. But 
sending on a broken connection causes the kernel to use the default values of 
`tcp_retries1` and `tcp_retries2` , leading to try to send a SIP message for 15 
minutes. This makes absolutely no sense in a real time kamailio application.

Following man 7 tcp TCP_USER_TIMEOUT can be used on recent Linux kernels to 
utilize tcp_send_timeout:

       TCP_USER_TIMEOUT (since Linux 2.6.37)
              This  option  takes  an  unsigned  int as an argument.  When the 
value is greater than 0, it specifies the maximum
              amount of time in milliseconds that transmitted data may remain 
unacknowledged before TCP will forcibly close  the
              corresponding connection and return ETIMEDOUT to the application. 
 If the option value is specified as 0, TCP will
              use the system default.

              Increasing user timeouts allows a TCP connection to survive 
extended periods without end-to-end connectivity.  De‐
              creasing  user  timeouts  allows applications to "fail 
fast", if so desired.  Otherwise, failure may take up to 20
              minutes with the current system defaults in a normal WAN 
environment.

              This option can be set during any state of a TCP connection, but 
is effective only during the synchronized  states
              of  a  connection  (ESTABLISHED,  FIN-WAIT-1, FIN-WAIT-2, 
CLOSE-WAIT, CLOSING, and LAST-ACK).  Moreover, when used
              with the TCP keepalive (SO_KEEPALIVE) option, TCP_USER_TIMEOUT 
will override keepalive to determine when to  close
              a connection due to keepalive failure.

              The option has no effect on when TCP retransmits a packet, nor 
when a keepalive probe is sent.

              This option, like many others, will be inherited by the socket 
returned by accept(2), if it was set on the listen‐
              ing socket.

              Further details on the user timeout feature can be found in RFC 
793 and RFC 5482 ("TCP User Timeout Option").

Having a tcp connection break by firewall or network breakdown the retransmits 
to this destination are now aborted after `tcp_send_timeout` seconds with a 

    NOTICE: <core> [core/tcp_read.c:267]: tcp_read_data(): error reading: 
Connection timed out (110) ([1.2.3.4]:51151 ->




You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/3528

-- Commit Summary --

  * core: Add TCP_USER_TIMEOUT socket option on listening socket.

-- File Changes --

    M src/core/tcp_main.c (13)
    M src/core/tcp_options.h (7)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/3528.patch
https://github.com/kamailio/kamailio/pull/3528.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3528
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/pull/3...@github.com>
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

Reply via email to