How hard can it be to send data from here to there?

Here's a list of possible reasons off the top of my head that you might fail to send data from here to there. Caveat: only things I have personally seen are included.

• The firewall port between the two machines was not open.
• The name was not yet in DNS.
• Forgot to configure a proxy.
• Forgot to disable a default proxy.
• The server starts but something else was listening on that port so there's an "Address already in use" error.
• The server restarted but did not use the SO_REUSEADDR flag so cannot reopen the same listening port for a few minutes.
• Loading data from a database but the JDBC driver was constantly copying an array into another array just 1KB larger triggering 99% CPU usage on garbage collection.
• A JSON document had an extra comma just before the final '}' making it not quite JSON.
• The system time was off by a day which causes all TLS negotiation to fail.
• I opened a scp session to a server that I already was sshed into, and "bank level" security detected two logins and caused my account to be immediately locked.
• A legacy server only supported older ciphersuites, and the client did not have lenient config.
• A legacy server only supported older TLS protocols, and the client did not have lenient config.
• A network link defaulted to 10MB half-duplex, dropping speed to a crawl (used to happed all the time in the olden days).
• "Hey, try this new opensource database query tool", I said. "Set up a connection here, oops that was the old password, it's probably changed... no that's wrong, too, try this... still nope? Oh, now the account is locked. Oh, and that's the service account that the UAT environment uses to connect to the database? Oh, damn, the client is in the middle of testing..."
• JDK upgraded and testing root cert not loaded into cacerts file.
• Certificate expired.
• Certificate name did not match DNS name.
• Netscaler swapped the first few bytes of "Content-Length:" header to make "ntCoent-Length:" which forces a connection close if transfer encoding is not enabled.
• RNAT configured on an endpoint available internally and externally causing returning packets to vanish.
• 6666 considered a "unsafe port" by Chrome.
• System admins had disabled SSH tunnelling on all ssh servers.
• Too many connections leak from a connection pool.
• Only one connection used for multiple users so that their transactions overlap.
• Failed to set binary mode using ftp client.
• Vendor's modem assigned DHCP IP a value outside of the range that other device from the same vendor was configured to allow access to the gateway.
• Connection did not have keepalive configured and eventually dropped.
• Connected to an HTTPS server as HTTP and vice versa.
• Server leaked file descriptors until it could not accept connections.
• Closing a connection failed, and I didn't think to catch the error.
• Forgot to flush after a send.
• Mismatch in character encoding, especially UTF-16.
• Forgot to add "Content-Type" header, resulting in a 415.
• Returning packets routed via a second server, which caused a stateful firewall to drop them.
• Connected to the wrong wifi network.
• Have not started the corporate VPN client.
• Didn't update password in local Python NTLM proxy, causing account to get locked.
• Forgot to do that PortableRemoteObject.narrow() with an EJB to allow the skeleton class to dynamically download to the client.
• Data updated in a cluster but never replicated to remote node.
• Network cable wiggled out.