Being on a non-C partition shouldn't be an issue unless F is a network share; it's been known to have issues over a network share. However, the fact that the connections are so poor for downloads would suggest that this is entirely a network issue. It sounds to me as if that system might be dropping packets left and right, which is kind of surprising given that you said it's not using WiFi.

Based on all your info, I'm entirely certain this is strictly a networking problem, though. So all investigative efforts should be focused in that direction.

Here's ping info to the hub.

Pinging hub.byond.com [199.168.119.52] with 32 bytes of data:
Reply from 199.168.119.52: bytes=32 time=275ms TTL=48
Reply from 199.168.119.52: bytes=32 time=281ms TTL=48
Reply from 199.168.119.52: bytes=32 time=282ms TTL=48
Reply from 199.168.119.52: bytes=32 time=292ms TTL=48

Ping statistics for 199.168.119.52:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 275ms, Maximum = 292ms, Average = 282ms

I doubt it, I turned my antivirus software and firewalls off to see if it made a difference with connecting to games - it didn't. My PC is scanned for malware once a week.

BYOND's the only software which gives this problem. Everything else I try works perfectly, but that could be attributed to those things having a good server infrastructure (i.e. Guild Wars 2, Dota 2, SWTOR, etc...).

Also, I asked a couple of IRL friends to download the pager and see if they could download games - it does exactly the same thing on their rigs (and they have MUCH better internet/PCs than I do), so I doubt it's something on my end.

Then again, it could be the distance between South Africa and wherever your server is located. Maybe we require a 20mb/s internet connection and 20ms ping to connect to games?

Also, the pager is really buggy. 3/4 of the time I need to clear my cfg files or it just refuses to start up. Sometimes, even then, it won't start up and I have to reinstall it.

Also, sometimes while it says Connecting..., ads randomly start, play, and then the game just stops at "Your game will start shortly". This happens when I click "Join" 5 times.

I could see how the locale might have something to do with it. Honestly I wouldn't rule out your ISP as the culprit.

See, that's the thing: Why is it stopping? The dropped connection is not the software's fault; it's using regular old TCP/IP that everything else uses. And that's Dream Seeker doing that, not the pager.

It could be that there's some congestion on the transport layer :P

Or it could be that the TTL on the packets is too low (I've run into this problem before). I'm thinking it's a question of congestion/distance playing in as a factor here, but it doesn't explain why it just suddenly started working.

Do you prioritize certain types connections somehow?

Recall that TCP has the Sliding Window protocol built into it, so it starts out sending packets at a slow rate and then increases it after successful acknowledgement. Since the increase of packets sent/received is slow, I can only think of congestion as a problem.

Also this suggests that I'm not getting acknowledgement packets from you guys - at least not at a fast enough rate for packets to be transmitted again from my side - thus, the connection times out. That's why it stops downloading.

We don't prioritize connections. The only thing BYOND does special with TCP/IP is that in Dream Seeker and Dream Daemon, we disable Nagle's algorithm for a faster server-client response. We're not altering the TTL at all from the default.

The lack or delay of a return packet would tend to indicate a problem at your ISP's end, especially since you're seeing this happen when you connect to games, not just to the hub.

Why would you disable Nagle's algorithm? You're sacrificing efficiency for performance (which makes no sense in itself, because efficiency usually leads to better performance), which means the reliability of your system is reduced substantially. Also, that performance increase which you get from disabling Nagle's Algorithm only benefits people with extremely fast internet connections - internet connections which can handle transferring large packets between the server effortlessly.

On a global level, you're dealing with people with different internet speeds. Factor in the average ping between locations, and the fact that the internet speed is slower as well, you're dealing with sending 41 byte packets over very large distances, and a lot of those packets can get lost as they travel from server to client. Furthermore, a lot of these 41 byte packets can be sent at the same time before any acknowledgement packet is sent.

That leads to Congestion Collapse, and it's why there's a lot of packet loss and as a result the connection drops for people who aren't in the US.

This is why the ad thing is causing connection drops too, because what's happening now is that the server is already sending me a large amount of 41 byte packets by downloading the game, which in itself already causes congestion - now you're sending streaming packets of the same size (i.e. they're transmitted much faster) for the ads as well, and I don't have enough time to send acknowledgement packets. Thus, congestion collapse and the connection drops.

Of course, this will only be a problem when we're downloading a game and the ads are streaming at the same time. It's not a problem if the game's already downloaded, which is why I can log into the downloaded game now just fine.

TCP Headers consist of 41 bytes - 20 bytes for TCP, 20 bytes for IPv4 and 1 byte for some other info.

So now, you're sending me 41 bytes in a packet to get at most one byte of information which can actually be used.

It's called the "small packet problem" - Nagle's algorithm attempts to overcome that by buffering output packages as long as there is a "sent packet" for which no "acknowledgement packet" has been received (until it has a full packet worth of data to send again), and as a result you don't have to continuously transmit useless amounts of packages to get useful response packets.

So by disabling Nagle's, you're bombarding the clients with large amounts of bytes in order to get a very small byte return - and you're sending -a lot- of them, which means you're causing congestion on the network.

Your timing issue arises because Nagle's purposefully delays transmission, but you can usually overcome that by setting TCP_NODELAY so that you bypass Nagle's delay.

If you can't fix it with that, use UDP. You can't sacrifice efficiency for latency - you're basically making long distance communication next to impossible except for people with godly internet transmission speed :P

Are you just outright disabling Nagle's? It's possible to only disable Nagle's for actual persistent game connections.

If the pager transfers bulk data (like a game) to the client, the application protocols will send a header first. The header is usually small, and if TCP_NODELAY is set on the socket then you'll get congestion collapse, because the packet with the header will then be transmitted immediately and will probably request an ACK packet as well. Thus, the transfer of bulk data will be delayed and unnecessary network traffic exchanged (i.e. congestion).

You can just use the TCP_CORK option on the socket - the header packet will be included with the bulk data and all the data will be transferred automatically in the packets according to size. When you're done transferring the bulk data you can just uncork the socket so that any partial frames which are left can be sent out. This will have the effect of optimizing how data is sent for things which don't need a persistent, real-time connection (i.e. game downloads)

So, use TCP_CORK option when you're sure that you will be sending multiple data sets together with no delays between them (i.e. Your game download and ad streams).

This would greatly improve the performance of the file transfers :P