Replies: 1 comment
-
In theory I have nothing against this change (except for the minor detail of maybe using Submit a PR and we can take if from there. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In our network we actively use
smcroute
to forward multicast traffic between sub-networks. The purpose of the network is very specific, so multicast routes change very often and use of thesmcroutectl
is required. The problem is that for every network change dozens of multicast routes have to be changed. Callingsmcroutectl
from, for example, shell script or even custom application is very slow, especially in embedded environment. Eventually I've come across few ideas:smcrouted
andsmcroutectl
is open, so it's possible to implement commands passing tosmcrouted
directly from our application;smcrouted
daemon accepts only one command at once then closes connection. So for every command it's necessary to create socket, make connect, send data, wait for an answer and close. May be it's more efficient to useSOCK_DGAM
to make it possible to send multiple commands at once with help of sendmmsg?smcrouted
daemon within existing type of IPC.I've implemented №1 as the most easy solution and situation became mush better but still far from ideal :)
The №2 requires a lot of changes in
smcrouted
andsmcroutectl
.Then I've tried to implement №3. On our embedded system this reduces execution of 10 commands (like adding 10 new multicast routes) delay by 4x-5x times!
Below is the proof of concept how it could be implemented on the
smcrouted
side:What do you think?
Beta Was this translation helpful? Give feedback.
All reactions