MNWis Fusion Technical Net
Monday Night 7:30 PM Central 0130 UTC
WiRES-X: MNWis #21,493
YSF: “US MNWis 21493”

YSF Reflectors

YSF reflectors are traditionally operated by individuals. The process involves:

  • Download the YSF Reflector source code from Github.com
  • Install the build tools for your platform (Visual Studio for Windows and “build-tools-essential” for Linux.
  • Perform the build, install necessary files, and adjust configuration files.
  • Open an incoming port (usually 42,000) and route it through the firewall to the program.

We’re trying to make this process easier. Soon we will publish a Windows executable that you can use to run on the same computer that runs your WiRES-X node. We’ll also publish binaries for the Raspberry Pi. As a third option, the YSF reflector can be hoasted in the “cloud”.

The “HamOperator” version of the program is a branch from the software that is in common use. However, we’re making some changes:

  • Fix existing bugs
  • Provide filters to prevent network traffic from messing up WiRES-X nodes. (Drop ‘DW’ packets, WiRES-X commands, packets with bad data, etc.)
  • Provide better logging that is more lightweight than the current PHP-based dashboard.
  • Provide more extensive control over how the reflector operates by selecting different options and features via the configuration file.
  • Better compatibility with a popular network by creating black lists and white lists of stations based on callsign and/or DP-ID.
  • Future integration with other Fusion network components.

On an experimental basis, we can support multiple YSF reflector instances in the cloud. This allows any number of servers to be coordinated and operate in the cloud permitting easier maintenance and simplified support.

Currently HamOperator is operating the following YSF reflectors:

Reflector Reflector # URL/Port
US MNWis 21493 37624 mnwis-ysf.ddns.net 42000
K9EQ 35806 mnwis-ysf.ddns.net 42001

US KENTUCKY

54780 mnwis-ysf.ddns.net 42002

Hosting

A YSF reflector needs to run on a computer – somewhere. This computer needs at least one port publicly exposed to the Internet so it can be reached by calling nodes. Most Hams will host their reflector on their home internet. This normally works okay, but can lead to problems:

  • There is no backup for the Internet service. If the service goes down for maintenance by the ISP or you need to reboot your router, rewire things, or you’re out of town when the computer crashes, your users may experience an outage.
  • A home ISP does not design their network for servers to be operating in the home. They are optimized for streaming data to you, not from you. Hence there may be bandwidth issues if your reflector becomes popular – especially while the family is streaming Netflix!
  • It’s not entirely about bandwidth. A lot of connections means a lot of small packets need to get in and out of your home very quickly. ISPs do not optimize for this and home routers may become overloaded with the large number of packets along with the large routing tables it needs to maintain for a large number of connections.
  • Computers can break and need to be replaced. Even if you have a spare on hand, it may take time to get the new computer up and running.
  • Your IP address may be assigned dynamically and there will be an issue for people connecting if your home IP address changes.

So hosting your reflector at home can work well, there are significant advantages to hosting “in the cloud”. Using “cloud services” you can host your reflector on a “rented” computer in a commercial hosting center. These centers typically offer multiple routes to the Internet Backbone, very high symmetrical bandwidth, provide emergency power, are protected from natural (or man-made) disasters, and have redundant hardware. Typically your “computer in the cloud” will be a virtual machine running along with many other virtual machines on a single, much larger, computer.

The cloud computer typically runs a version of Linux. (Windows servers need to pay a Microsoft license fee. This, along with greater hardware requirements, means that a Windows cloud server will typically cost much more.) The cloud computer has no GUI and is run by using SSH to bring up a terminal window. From the command line you can make modifications, install software, transfer files, and manage your server applications.

You typically run the computer from a dashboard provided by the hosting company. From this dashboard you can start your computer, configure it (number of CPUs, RAM, etc.), and stop it. Virtual servers can be charged by the month or by the hour. In the latter case you are not charged when you “destroy” or erase it. The pricing is based on the amount of CPU power you need and RAM. In some cases you may be charged for bandwidth, disk storage, etc.

If you’ve heard of Microsoft’s Azure, or Amazon’s AWS, these are cloud services that you can buy.

Costs can vary widely depending on the vendor and can be as high as $75/mo, or less than $5/mo. Using a smaller provider (not Amazon, Microsoft, or Google) can result in a lot of capability for not much mode.

The reflectors listed above are running on a single Linux machine (1 CPU, 1 GB RAM) that costs $5/mo. to operate. It probably has enough capacity to run 20 – 50 reflectors. An advantage of hosting is that all of the reflectors can run the same copy of the reflector software.

If you are interested in using the same service I use, please contact me. I can provide you with a link that will give you $100 of credit to use of 60 days. That can be a lot of experimenting on their dime.

Last Updated on