<div dir="ltr">OK. Thank you for detailed answer.<div><br></div><div>Let me discuss it internally and see what is best way to deal with it. If possible I will try to write up a patch for per socket tcp buffer sizes and submit it to you guys for inclusion in kamailio trunk.</div><div><br></div><div>Thank you.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 2, 2017 at 3:19 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<span class=""><br>
<br>
On 02.05.17 13:02, M S wrote:<br>
> Hi,<br>
><br>
> I have a kamailio v4.4.5 deployment that serves TCP clients for SIP<br>
> and XCAP requests (without SIP presence). The kamailio's core TCP<br>
> parameters allow us to set TCP read and write buffer sizes which are<br>
> set globally for all TCP connections.<br>
><br>
> However, i noticed that in general SIP over TCP request is much<br>
> smaller (<8KB for audio + video SIP INVITE request) then XCAP requests<br>
> (say to support up to 500 contacts we need TCP buffers =~ 64KB).<br>
><br>
> So, if I set global TCP buffer size according to XCAP service needs<br>
> (e.g. 64KB), they waste too much RAM for SIP connections (assuming max<br>
> SIP packet is  8KB, there is 56KB buffer space wasted per connection).<br>
><br>
> On the other hand, if i set global TCP buffer sizes to SIP service<br>
> needs (e.g. 8KB) then it is insufficient for XCAP (only 70-80 contacts<br>
> would fix in XCAP list).<br>
><br>
> Therefore, i am looking for a way to allow TCP buffer size settings<br>
> per connection OR per module basis. Is it possible? If so then how?<br>
</span>at this moment is not possible to set the buffer size per connection.<br>
The connection structure is created before knowing what is going to be<br>
received on it.<br>
<br>
Also, not per module, because the module is agnostic of the transport layer.<br>
<br>
An enhancement might be to specify it per socket, so when listening on<br>
port 5060, then use a specific buffer size and when listening on another<br>
port like 8060, use a different buffer size. But this requires C coding.<br>
<br>
On the other hand, the latest kernels use the physical memory only when<br>
writing. So if one allocates 2GB and uses only 10MB, only 10MB are used<br>
from the physical memory, the rest is just virtual memory.<br>
<br>
Cheers,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
Kamailio Advanced Training - May 22-24 (USA) - <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
Kamailio World Conference - May 8-10, 2017 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
</font></span></blockquote></div><br></div>