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

YSF Reflectors

Operating with a YSF Reflector

YSF and FCS are two different reflector systems that can be used with Yaesu’s System Fusion. YSF, FCS, WiRES-X, and IMRS are three INDEPENDENT networking systems. Hotspots can only connect to YSF or FCS reflectors. A station on a given reflector system can only talk to other stations on that system unless the system has been bridged.

YSF Reflectors have a name such as “US MNWis    RDNT”. They are also referenced via a 5-digit code, such as “21493”. A 5-digit code was chosen since WiRES-X also uses a 5-digit code. This allows hotspot software, such as Pi-star, to use the WiRES-X control capability in Yaesu radios to change the YSF reflector that the hotspot is connected to.

It is important to note that the 5-digit YSF code is not necessarily the same as the 5-digit WiRES-X code. For example, AmericaLink is on WiRES-X Room #21,080. The AmericaLink YSF Reflector is #89804. The WiRES-X Room and the YSF Reflector are connected together because of a bridge operated by AmericaLink. Note that some YSF Reflectors and their bridged WiRES-X room use the same number. More info here.

A list of all YSF Reflectors is available here: YSF Reflectors

Operating a YSF Reflector

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    RDNT 21493 mnwis-ysf.ddns.net 42000
US K9EQ      DYEF 12345 mnwis-ysf.ddns.net 42004

US KENTUCKY

42806 mnwis-ysf.ddns.net 42002

US MVARC

43210 mnwis-ysf.ddns.net 42003

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, follow This Link that will give you $50 of credit to use of 30 days. That can be a lot of experimenting on their dime.

Last Updated on