Setting SO_RCVBUF in SFC?

Is it possible to setSO_RCVBUF in SFC on the socket of the connection to P2PS? (the default size set by the OS is inadequate - about 100k)

I couldn't see any mention of it being possible in the SFC docs.

We have some fairly busy market data consumer applications that would benefit from a larger socket buffer smoothing out spikes in the incoming market data - sometimes the spikes are too big and result in the client being kicked off P2PS, which is more disruptive to us than purely queuing the data at the expense of latency.

Find more posts tagged with

trep

elektron

refinitiv-realtime

Accepted answers

DevTrev

Here are some ideas:

Increase the OS default values. This will of course affect all applications on that host.
Increase buffer size in the P2PS (nowadays called ADS). This will of course affect all consumers that use this specific ADS. I've seen some sites that deliberately set aside a dedicated ADS for slow legacy consumers. Such ADS would then have buffer size much higher than the default.
Enable TrafficManagement on the ADS. This is a feature of the ADS whereby it will automatically start conflating the updates if it detects that the consumer is falling behind. The way it detects this is by looking at the consumer channel's buffer utilization and when it gets above a certain threshold it will start conflating. You should of course only enable this feature is conflating is acceptable to you. I suspect that a very sudden and big burst may come too quick for this feature to kick in in, in other words: the feature cannot guarantee you that you'll never be kicked off the ADS again. Also, for conflation to have an effect there needs to something to actually conflate. If the updates are spread out on many data items (rather then within a data item) then conflation has no effect.
Finally, and I'm sure you know this and don't want to listen to this : You are really treating the symptom, not the problem. You've got a slow consumer on your hands and on top of that you are using what can best be described as a legacy API. With the newer APIs (RFA) you would be able to alleviate the problem simply by using configuration variables even if your code logic was not as fast as one would like. Also the default mode of RFA is to read messages from the wire in a separate thread and the message is then put into a queue for the application to consume when it is ready to do so. Thus the ability to handle spikes is only limited by the memory available to the application which is a very suitable model for your scenario (don't care about latency). This is why you should try to be modern with your consumer.

All comments

DevTrev

Here are some ideas:

Increase the OS default values. This will of course affect all applications on that host.
Increase buffer size in the P2PS (nowadays called ADS). This will of course affect all consumers that use this specific ADS. I've seen some sites that deliberately set aside a dedicated ADS for slow legacy consumers. Such ADS would then have buffer size much higher than the default.
Enable TrafficManagement on the ADS. This is a feature of the ADS whereby it will automatically start conflating the updates if it detects that the consumer is falling behind. The way it detects this is by looking at the consumer channel's buffer utilization and when it gets above a certain threshold it will start conflating. You should of course only enable this feature is conflating is acceptable to you. I suspect that a very sudden and big burst may come too quick for this feature to kick in in, in other words: the feature cannot guarantee you that you'll never be kicked off the ADS again. Also, for conflation to have an effect there needs to something to actually conflate. If the updates are spread out on many data items (rather then within a data item) then conflation has no effect.
Finally, and I'm sure you know this and don't want to listen to this : You are really treating the symptom, not the problem. You've got a slow consumer on your hands and on top of that you are using what can best be described as a legacy API. With the newer APIs (RFA) you would be able to alleviate the problem simply by using configuration variables even if your code logic was not as fast as one would like. Also the default mode of RFA is to read messages from the wire in a separate thread and the message is then put into a queue for the application to consume when it is ready to do so. Thus the ability to handle spikes is only limited by the memory available to the application which is a very suitable model for your scenario (don't care about latency). This is why you should try to be modern with your consumer.

EXPLORE OUR SITES