Who said they would actually put it in a new version?
Just think of how possible internet play would be when messing with another tarball or the same object, or when none of them apply but timing is important (dragster). And even if that would not happen it would make Gish difficult to handle, because it doesn't get the data from the other computer in realtime, which can affect you because the other one may go to where you want to go, causing a collision in other timesteps than the simulation, making life difficult both for programmers and players (especially with Gish, for which total realtime is critical).
Over a LAN the timesteps could be the same because it is fast enough, even on awireless 802.11b. With normal 64 bytes ping packets, I get a reply within 3 ms. 1024 bytes its still about 8.5 ms (that's computer > access point > switch > router and back).
On a wired 100 Mbps network with a few tens of meters of UTP cable directly to the router (which has its own built-in switch), I get 400 µs for 64 bytes, and less than 2 ms for 8192 bytes (the limit).
But when pinging the wired network from the wireless network over the internet (7 hops) I get 20-30 ms for 64 bytes. When doing that for 8192 bytes, I even have to wait for 430-460 ms.
Now lets say you have 100 floats you want to send in a simulation with 100 steps per second. That means you should be able to send and then receive 400 bytes (not including protocol overhead and maybe errors) within 10 ms, which is far less than the 40-50 ms I get over the internet. But Gish needs far more than 400 bytes, making realtime even more impossible.
That means Gish is only really playable over a LAN, not the internet (either very slow or the way I described earlier).
Hint for CL (if something is going to be done): you can use the first bytes for 'locations changed' packets on bit-level to tell which variables changed (maybe using limited directory-like hierarchy), and the following ones for the actual data. The very first byte could tell what kind of packet it is (locations changed, nothing changed, join, accept, decline, exit, etc.).
And in case you're interested, my 5.7 pound computer supports 802.11g and gigabit ethernet, but the networks I described don't.
Just think of how possible internet play would be when messing with another tarball or the same object, or when none of them apply but timing is important (dragster). And even if that would not happen it would make Gish difficult to handle, because it doesn't get the data from the other computer in realtime, which can affect you because the other one may go to where you want to go, causing a collision in other timesteps than the simulation, making life difficult both for programmers and players (especially with Gish, for which total realtime is critical).
Over a LAN the timesteps could be the same because it is fast enough, even on awireless 802.11b. With normal 64 bytes ping packets, I get a reply within 3 ms. 1024 bytes its still about 8.5 ms (that's computer > access point > switch > router and back).
On a wired 100 Mbps network with a few tens of meters of UTP cable directly to the router (which has its own built-in switch), I get 400 µs for 64 bytes, and less than 2 ms for 8192 bytes (the limit).
But when pinging the wired network from the wireless network over the internet (7 hops) I get 20-30 ms for 64 bytes. When doing that for 8192 bytes, I even have to wait for 430-460 ms.
Now lets say you have 100 floats you want to send in a simulation with 100 steps per second. That means you should be able to send and then receive 400 bytes (not including protocol overhead and maybe errors) within 10 ms, which is far less than the 40-50 ms I get over the internet. But Gish needs far more than 400 bytes, making realtime even more impossible.
That means Gish is only really playable over a LAN, not the internet (either very slow or the way I described earlier).
Hint for CL (if something is going to be done): you can use the first bytes for 'locations changed' packets on bit-level to tell which variables changed (maybe using limited directory-like hierarchy), and the following ones for the actual data. The very first byte could tell what kind of packet it is (locations changed, nothing changed, join, accept, decline, exit, etc.).
And in case you're interested, my 5.7 pound computer supports 802.11g and gigabit ethernet, but the networks I described don't.
:'>