[We've gone back and forth several times today about this issue. This is the latest message in the trouble ticket system. I'm not trying to make fun of the customer, but man, it is so tempting … —Editor]
Our clients can not update their sites and they are suffering … Can't you route the communication to that server in a different way?
“One of our resellers”
Dear XXXXXX,
You know, you're right. We haven't tried rerouting FTP (File Transfer Protocol) packets to the server. Let's see … we can peel off the FTP traffic from the HTTP (HyperText Transfer Protocol) traffic at the Primary Intarweb Interface Matrix and feed it through the secondary sub-intranet bridge instead of through the primary LAN (Local Area Network) tokenizer substation hub … hmm … while the FTP traffic is now going to the secondary sub-intranet bridge it's not getting past the IEEE (Institute of Electrical & Electronics Engineers) 802.3 CSMA (Carrier Sense Multiple Access)/CD (Carrier Detect) packet scrubber. Odd.
Okay, instead, let's see if I can reroute the traffic from the secondary sub-intranet bridge through the dual-Φ power transformer at … let's see … probably need to make sure the bits are phased at 60Hz (Hertz) at 51.5° (to induce harmonic pyramidal overtones), making sure to bypass the GFCI (Ground Fault Circuit Interrupter) (dangerous, I know, but if you know what you are doing, and are very careful, it should be okay) and then tap the secondary coil on the server in question, couple it to the APCI (Advanced Configuration and Power Interface) DMA (Direct Memory Access) via the unused SCSI (Small Computer System Interface) controller and then finally into the TCP (Transmission Control Protocol)/IP (Internet Protocol) stack … and—
Cool!
It worked!
Try it now!
Now, off to repair the primary LAN tokenizer substation hub.
[And no, despite how tempting it might have been, I did not send this as a reply, but instead restarted the FTP server.]