Well,
if you were to use conpgm
and in the related script, call
https://stats.allstarlink.org/api/stats/node#
You could grab and evaluate required info, even if you are just looking for a wide node in the other system.
And while you could not prevent the connect, you could issue a disconnect right after.
To clarify I was not suggesting any central point manage this for multiple nodes. This would be done on one node at a time on that local node. eg. if Bob has node 45678, I would provide him a PHP script that he would put somewhere on that node and he would add a few lines to the necessary .conf file(s) to for example have the script get called before and after connect events occur if that’s possible, or otherwise to run as a daemon and monitor the rpt xnode and connected node list stats once per second and look for changes. And then yes as Mike mentioned, if you then see a new node in the list, and NUMALINKS just increased by 50, then disconnect that last node.
To Mike, not sure what you’re referencing with the connpgm and discpgm, are those lines that would be added to a .conf file? Which one?
rpt.conf
They work well, I have used them many times in the past. But not anymore.
Each node may have it’s own in it’s stanza.
Just checked and don’t think it is in the wiki and not sure they were ever documented.
Something to add in the future I guess.
Between the connpgm hook and/or periodic checks of the local rpt xnode stats it should be pretty simple to detect when the connected node count gets too high (either above a max total limit or above an incremental threshold) and something needs to be done. Again this would only look at local stats and a flattened list of nodes instead of a real network graph data structure, but in having very briefly looked through app_rpt.c earlier today it seems it does only maintain an array list of nodes rather an actual graph data structure. (Though I did not look at it closely enough to say for sure. The file has 25K LOC.) But in terms of network performance it would make more sense for Asterisk to send IAX audio packets directly to all connected nodes rather than those packets being routed through some potentially large number of hops in the node graph. To do the latter would be more efficient in terms of CPU and local network bandwidth, but would introduce long latencies in the audio stream to nodes that were multiple hops away on the connected node graph. (Someday I am going to take a closer look at IAX2 and confirm how all the routing works at the IP level.)
BTW this could all be done relatively easily in app_rpt itself, with probably less than 50 lines of C code, which I also wouldn’t mind doing (I was a C developer from 1993-2011), and a new cfg parm could be added defining a max limit of “connection baggage” a connected node was allowed to bring, but it is more involved and requires much more testing to build something like that into app_rpt itself, though could be a nice long-term feature, which if left turned off by default in the conf settings would be low risk change. Before doing that though it would definitely be good to prototype, test and refine the feature externally to app_rpt and then if in a year or so there were dozens of repeater systems successfully using it then maybe move the logic into app_rpt.
Only something like ‘playback’ would announce on all nodes.
Each connected node controls it’s own telemetry and may be turned off all together.
But using the API link above can tell you how many nodes the conectee has at the time of connect.
You do have to parse the returned data.
Somehow I thought there was a ‘maxnodes’ parameter. But I don’t see it.
Would not be the first time my wires were crossed.
I’m must be missing something, I still don’t understand why all the complexity… since each incoming connect has to pass through Asterisk’s Dialplan every incoming connect request to YOUR node or hub, it should be able to be filtered on a per node basis and be directed to, finish the connect or reject it (with a message) saying why, all depending on the filter criteria.
Doesn’t need to be a full time global script to hammer the stats page for every single connect of the entire Allstar System. Just something that people who are are having issues could add to their system while the LIDS either get things corrected or be Blacklisted.
What I’m seeing suggested on here is way to complex to stop a few issues while training people on what not to do.
Larry - N7FM
Can we back up for a second, what exactly is the goal here? Do we simply need to limit the number of nodes in a given network of connected nodes and if so why? Is it due to crashes or another reason?
Have we established that xnode RPT_NUMLINKS has the total number of connected links and RPT_NUMALINKS has the number of directly attached links?
I’m pretty sure theses correspond to link,5 (connected nodes) and link,15 (all connected nodes).
Speaking purely for myself,
It would be nice if you could set a limit to the max connected nodes. This helps with anyone with a low-bandwidth situation from a crash when the limit has been reached.
But you might also need to signal the conectee the reason for the refusal.
Most of the policing should be admin personally intervened. Because one size does not fit all. It has wider implications such as connecting to a net with plenty of connections. And that would be much harder to code for each implication. Some of which we may not fully imagine just yet.
After reading what I wrote a few times,
I know there is the possibility of scripting this by watching the number of nodes connected and just NOICE commanding. And the opposite when the number is reduced.
But I do feel it should be a built-in parameter for future releases so that proper signaling can be archived to the contectee when connection is refused to avoid lots of confusion.
Kinda the same thing needed with the LOOPBACK protection refusals.
I think you just nailed it, Mike, when you mentioned command state NOICE. That and cop,49 disable incoming links.
I think a script that monitored RPT_NUMLINKS and issued a cop,49 above a given threshold and a cop,50 when below the threshold, would do the job nicely for preventing inbound connections.
Outbound connections are another matter. That would work something like the white/black dial plan setup. I’ll think about that some.
As far as signaling the other end to would be nice to have a response that triggered a “The admin has disabled links” message.
Ideally all of this would be a feature of AllStar rather than having to script it.
To first Address Larry’s comment: The solution proposed is actually very simple. What is a little more complex, is the issue itself, which requires repeater system owners to babysit their systems, so that inexperienced users do not inadvertently connect other large systems.
Discussion of the details and nuances of the issue also may appear complex, but one should not assume that detailed discussion implies complex solutions.
All properly designed software systems have mechanisms to insure the stability of individual nodes and of the overall system. I have implemented a variety of simple algorithms in the past, including congestion-control algorithms for the Orbcomm Satellite network, and rate-limiting mechanisms for enterprise web portals that precisely measure CPU use of multiple servers in real time, ensuring system stability even if bombarded with D.O.S. attacks. From a mathematical standpoint these algorithms are simple and work reliably.
To someone who does not have a software engineering background this discussion sounds complex, but again that does not mean a solution itself is complex. Might only be a few dozen lines of code involved, and it does not require as Larry states: “full time global script to hammer the stats page for every single connect of the entire Allstar System”. That is not at all what was discussed, even though it understandably might appear as such to a layperson.
If the OP or another repeater system admin would like a solution to this issue I am happy to put one together, and with the experience that Tim, Mike and others on the forum have I have no doubt the end result would be a simple and effective solution that increases the stability and usefulness of AllStar for everyone.
Following up on other comments, I do still think the immediate goal is simply to boot any user who has more than X number of other connections. eg. a system owner can set X=5 in a conf file and then if node 2345 connects to your node, then later also connects to another node having 50 connections, then 2345 gets disconnected.
Secondary checks can then also be easily added, maybe if your node has > maxnumconnections that you define, then parse the node graph and drop the node with the most connections. But there are a lot of options there and a number of possible approaches.
Very well put and understood David.
It was from the outside looking in, it appeared to be going in the complex direction. Mike and Tim have probably steered the original intent back to the path needed for the solution if utilizing node counts to refuse connects.
Larry - N7FM
There is no one size fits all for someone who drags a wide active connection with them.
I have at times 20 of my own public and private nodes connected together at once.
The native activity is minimal.
Using count of the contectee’s connects is not likely the answer.
Blocking those that drag with them ‘known wide active systems’ (by node number) is a more reasonable approach if anyone wants to achieve that. But even that is not going to go smooth for everyone.
The specific purpose of having a maxnodeconnects (local) is strictly for those with bandwidth issues.
System resources can be optimized/constrained according to any combination of metrics such as node counts, network (IP) bandwidth, keyed node activity levels, or local node CPU use. The steps to find an optimal solution could generally be described as follows in case anyone’s interested:
In any system the more accurate your input data, the more accurate the output data and results. Graph theory is a whole branch of math and computer science that deals with exactly these kinds of optimizations, ie. how to move information within any arbitrary network topology in the most efficient and reliable way. Applying these concepts to AllStar can ensure a truly optimal long-term solution that maximizes stability, reliability and convenience for all users. For a CS or EE pro with a couple decades experience in optimizing these systems, well that’s what we do. Like a master carpenter building a staircase that’s solid, simple, attractive, easy to use, durable and reliable - it’s complex to someone who hasn’t done it before, but second nature for a good carpenter with 30 years of experience.
Thus why I looked at the possible data sources and tradeoffs involved. Better to have a complex / confusing discussion that results in a simple and optimal solution, vs. the other way around.
Having a true ASL node graph data structure would enable optimal solutions to these kinds of resource optimization issues. This data does not change greatly from minute-to-minute and could be shared in very bandwidth-efficient ways eg. by sending diffs rather than full data structures, or with P2P routing between nodes which would minimize any load on the ASL servers. These details are beyond the scope of this thread but just wanted to mention that sometimes a little time to look at things from a higher level Math/CS standpoint can achieve optimal results that do exactly what users really want in the simplest way. ASL has this data in their DB already so the foundation is already in place. But there are other valid approaches also, and either way this is a fundamentally important use case to look at and maybe we figure something out now, or maybe the OP already moved on and forgot about it and someone else will bring it up again in a few months.
Anyone know if this was ever implemented? I too wish to prevent inbound connections by nodes that are also connected to X other nodes.
If ‘what’ was ever implemented ?
The underlying theme of this thread: ability to take action against inbound nodes with ‘baggage’, i.e. a large number of indirectly connected nodes.
This was just a discussion as to what methods an individual node owner might use to limit that.
And it comes with more baggage then help to do that indiscriminately without knowing the traffic on said connection.
So, no, nothing new has ever been ‘implemented’
There is noice, whitelist and blacklist to quickly address this.
If some node is bringing a lot of unwelcome nodes in a connection with you, put that node on your blacklist. They will not be able to do it again. It does not affect anyone else.
To much work ?
Thanks for the reply, Mike. I don’t want to blacklist any of my regular inbound connections, just guard against the occasional instance when they’ve forgotten to disconnect from another large network before joining mine.