Recv buffer size and system limits in ETA

Hi,

I have an application that use the ETA to receive market data. I am looking at impact of "sysRecvBufSize" when I create a channel.

I set "sysRecvBufSize" to 64 MB, and I check the value using "rsslGetChannelInfo" after the channel has been connected. I get a "sysRecvBufSize" value of 128 MB. However, I believe this conflict with the system memory limits. Using "sysctl -a", I get an net.core.rmem_max value of 83886080 and a net.ipv4.tcp_rmem maximum value of 16777216.

Does "sysRecvBufSize" reflect the real size of the recv buffer size ?

Thank you

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

Accepted answers

Jirapongse

@didier.nadeau

Refer to the TCP Linux Programmer's Manual, TCP actually allocates twice the size of the buffer requested in the setsockopt(2) call.

The maximum sizes for socket buffers declared via the SO_SNDBUF and SO_RCVBUF mechanisms are limited by the values in the /proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max files. 
Note that TCP actually allocates twice the size of the buffer requested in the setsockopt(2) call, and so a succeeding getsockopt(2) call will not return the same size of buffer as requested in the setsockopt(2) call.

Therefore, it is why it returns 128MB when setting the receive buffer size to 64MB. Moreover, you may need to verify the value in the /proc/sys/net/core/rmem_max for the limited value of SO_RCVBUF.

All comments

Jirapongse

@didier.nadeau

Refer to the TCP Linux Programmer's Manual, TCP actually allocates twice the size of the buffer requested in the setsockopt(2) call.

The maximum sizes for socket buffers declared via the SO_SNDBUF and SO_RCVBUF mechanisms are limited by the values in the /proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max files. 
Note that TCP actually allocates twice the size of the buffer requested in the setsockopt(2) call, and so a succeeding getsockopt(2) call will not return the same size of buffer as requested in the setsockopt(2) call.

EXPLORE OUR SITES