As it seems I'll never rest until either everyone can download from RE without any issues or I go crazy from a lack of rest I spent most of today researching further into the RailPro UDP problem. Today I discovered something that could be very pertinent to the problem. Google!
Ok, Google itself is not to blame but the reaction by the community (ISP's, firewall and cache system makers) is. The story goes like this: Back in about 2012/2013 Google had decided TCP was too slow and set about making a faster protocol for use on the internet. What they come up with was QUIC - Quick UDP Internet Connections. Since this UDP based protocol would be used for web based stuff the port of choice was 80 and 443; the common everyday ports for http/s connections. What happened is once people realised that this new UDP based protocol could not be effectively filtered (you are being watched!) or cached they pulled a knee-jerk reaction. I have in front of me no less than 9 urls from firewall and cache system manufacturers that explain to simply "block UDP traffic on port 80" to stop this QUIC protocol.
Chrome, the only consumer software that can use QUIC at the moment is fine with this, it simply switches back to TCP if it can't use QUIC. It's a much bigger problem for us, The installers for HC Simulator and RailPro Assistant, and RailPro Assistant itself use UDP on port 80 to communicate to Ring's server with no fall back incase UDP can't be used.
I don't know how widespread this blocking of UDP on port 80 to stop the QUIC protocol from being used is (and therefore bypassing filtering and caching at the ISP level) is with Internet Service Providers; it's something they won't publish online for sure but it could be a big reason why many cannot connect to RE to install or download to RPA.
To fix this one Tim Ring needs to add a fall back to TCP or another UDP port in his software.
- Tim
