05-26-2016, 09:36 PM
I came up with a way to use the timing mechanism better. Ping was a big limiting factor on saving bandwidth. Someone with 50ms ping could only save 10 bits per second. I just now realized that ping may only so fast. For example, my ping with google is between 100ms to 200ms roughly. So instead of using 200ms toggle, I could instead use 100ms toggle and assume all messages will arrive after 100ms passes. Another example is that a person with 40ms-50ms ping garunteed can use a 10ms toggle, and always assume a message will be delayed by 40ms. By doing that, I just made the bits saved per second 5 times more/faster. Another speed up it that I should measure ping one way, server to client. If I use ping this way, rather than round trip ping, it doubles the speed. Still only 100 bit+100bytes/second but using this method 10x faster than the old method.
The more consistent the ping and the less randomness in the time stuff is receive, the faster the method. Someone with a ping of 100-102ms ping would do much better than someone with 45-50ms ping using this method: the slower ping guy would receive data 2.5x faster compared to the faster ping guy IF they both use the same method.
I feel the method needs refined more, but I'm hoping I can keep pushing the method farther. The data savings are still making the file's bandwidth savings 8/9 the size, but I'll worry about saving more after this method gets faster.
The more consistent the ping and the less randomness in the time stuff is receive, the faster the method. Someone with a ping of 100-102ms ping would do much better than someone with 45-50ms ping using this method: the slower ping guy would receive data 2.5x faster compared to the faster ping guy IF they both use the same method.
I feel the method needs refined more, but I'm hoping I can keep pushing the method farther. The data savings are still making the file's bandwidth savings 8/9 the size, but I'll worry about saving more after this method gets faster.