I’m quite curious about the back-end architecture of the new ASL infrastructure. I know a lot of time and effort was spent trying to make the previous generation of systems robust, and due to that process and subsequent updates I felt like I had a decent understanding of the registration and stats server layout prior to the move to Google’s cloud platform. I understand that the new system required significant effort as well.
Would the admin team of the new system be willing to talk for a bit about how the system works, and how it differs from the previous generation system?
I’m also curious about how the Google cloud platform services are funded. Is this primarily from donations, or are there other revenue streams to ASL?
This post isn’t intended to be political in nature between ASL and PTTLink; I’m just genuinely curious how it all works. I’m not affiliated with either group. I will admit to donating a few bucks to ASL back in the N4IRS days though.
I second that sentiment. I think some sort of network or system diagram would go a long way to illustrate the moving parts and help understand how they interact with each other. It would also help put things in context when someone argues that some aspect of the system is flaky or that their version of the system is somehow superior.
Realistically, the Board will probably never be able to publicly disclose complete details on the system architecture.
It was the same situation with a linked 2M repeater system that I used. Everyone knew the frequencies and tones of the nodes, but the details of the 440 interconnections were never publicly disclosed.
It only takes one disgruntled bad actor armed with infrastructure details to cause a tremendous amount of disruption.
When the Board is “ready”, I would be very interested to learn more about the rationale behind the change in the registration system and at least some of the details.
You can probably get the complete picture of the system architecture by following steps similar to those in any open source software project. Volunteer to help, make some contributions, and over time you will learn more about the system as you gain the trust of other contributors and the Board.
Realistically if the board is actually committed to this as an open source project the architecture of the complete system should be published. The analogy of a linked repeater system is a good one. The link frequencies may not be public but what links to where can be and probably should be. In the case of allstar the specific ip addresses for the ip endpoints need not be published ht the fact that this module connects to that module that connects to and/or interacts with one or more specified other modules and how those connections are done should be published. If the inherent design has its security dependent upon ones advosary not knowing the structure, then there really is no security. Good security depends not upon preventing the spread of knowledge but upon good design and engineering. Take for example public key cryptography. It is secure not because the algorithm is published but instead that it depends upon functions that are escentially one way in operation without knowledge of the public and private key pairs. (Multiplication is easy, factoring large numbers is hard). The same types of things can be put in place in large complex systems to secure them. I call upon the board to publish the architectural details of the new system.
We’re in the early stages of our new infrastructure, so some pieces are constantly changing. I joined this project with the intention of my work being open sourced, so once we’re all ready to do so, we’ll be publishing pieces of the infrastructure code on Github. Once we regain control of our previous Github page, we’ll make sure all of the legacy code stays up as well.
We want the ability for new volunteers to find flaws, add features, and contribute to the project in any way possible. So I’m with you on that!
As for the new infrastructure, our focus is simplicity and resiliency. We want AllStarLink’s infrastructure to require as little maintenance as possible so that we can focus on our core: ASL and the ham operators.
The registration server was completely rewritten as a NodeJS application for facilitating the IAX communication with ASL clients – it’s a sort of Asterisk emulator. This reduced the need for complicated load balancing, and we have redundant registration servers now simply for fault tolerance (but the effect is load balancing as well ). In our early testing before going live, we determined that we can have up to 15,000 registrations per server (more, but comfortably this amount), whereas before we could only handle around 1,000 per server.
Stats has been completely rewritten to move off of C/CGI so that we can more easily maintain the code, add features, and provide JSON APIs for users in the future. We’ve largely kept the same layout for stats but given it a slight facelift.
Other than that, most of ASL remains as before. We’ll provide updates as things change and of course when we publish code!
We’re in the early stages of our new infrastructure, so some pieces are constantly changing. I joined this project with the intention of my work being open sourced, so once we’re all ready to do so, we’ll be publishing pieces of the infrastructure code on Github. Once we regain control of our previous Github page, we’ll make sure all of the legacy code stays up as well.
We want the ability for new volunteers to find flaws, add features, and contribute to the project in any way possible. So I’m with you on that!
As for the new infrastructure, our focus is simplicity and resiliency. We want AllStarLink’s infrastructure to require as little maintenance as possible so that we can focus on our core: ASL and the ham operators.
The registration server was completely rewritten as a NodeJS application for facilitating the IAX communication with ASL clients – it’s a sort of Asterisk emulator. This reduced the need for complicated load balancing, and we have redundant registration servers now simply for fault tolerance (but the effect is load balancing as well ). In our early testing before going live, we determined that we can have up to 15,000 registrations per server (more, but comfortably this amount), whereas before we could only handle around 1,000 per server.
Stats has been completely rewritten to move off of C/CGI so that we can more easily maintain the code, add features, and provide JSON APIs for users in the future. We’ve largely kept the same layout for stats but given it a slight facelift.
Other than that, most of ASL remains as before. We’ll provide updates as things change and of course when we publish code!
). In our early testing before going live, we determined that we can have up to 15,000 registrations per server (more, but comfortably this amount), whereas before we could only handle around 1,000 per server.
|