My friend who has offered to lend a hand with my sim in the networking
department has come up with a question. Is compressing packets a good
idea in network ***?
I would have thought that as the speed of pc's increase and increase the
time needed to compress/decompress will become small enough to make it
beneficial for low bandwidth connections.
Does anyone have any insight?
All the best,
Ash
>My friend who has offered to lend a hand with my sim in the networking
>department has come up with a question. Is compressing packets a good
>idea in network ***?
>I would have thought that as the speed of pc's increase and increase the
>time needed to compress/decompress will become small enough to make it
>beneficial for low bandwidth connections.
So the question is indeed; is network bandwidth generally growing at a
greater rate than CPU bandwidth?
Ruud van Gaal
Free car sim : http://www.racesimcentral.net/
Pencil art : http://www.racesimcentral.net/
Note, you dont want to have to rewrite every time you do a major updgrade so
if the packets are too big, you may be better off spending your time on
finding ways to send the information using less data like sending (and
reading) in hex, using preloaded tables, prediction code, and making sure
the server isnt doing ANYthing the client can do by itself.
Also, make better choices on what repetitive data is important. An example
would be using tables on the server to store what is needed for prediction
code. Use algorithims to only change the tables on some point of accuracy,
meaning dont simply always update the table every warp free lap, etc.
--
Tim White
INTRAC Motorsports
www.birds-i-view.com/intrac
In racing networking code you need to send a lot of packets per second
so you have to have them small, but small packets do not compress well
using generic algorithms.
However, you can employ your own methods. For example if you need
to send car position you may send it let's say as 4 byte value
relative to the track or alternatively only 2 lower bytes of it.
In 99.99% percent of cases other side can figure out what are high
bytes from the previous data. However you will need to write extra
code to handle special cases (big network lags etc) when recepient
feels that received data are suspicous.
Using bit structures also helps, however it adds work especially
if you want to support cross-platform multiplayer (which you
probably don't, because Linux and Windows run on the same architecture).
Alex.
>> Does anyone have any insight?
>> All the best,
>> Ash
cheers,
uwe
--
Uwe Schuerkamp //////////////////////////// http://www.schuerkamp.de/
Herford, Germany \\\\\\\\\\\\\\\\\\\\\\\\\\ (52.0N/8.5E)
Ever wondered what's wrong with the world? http://bnetwork.com/
PGP Fingerprint: 2E 13 20 22 9A 3F 63 7F 67 6F E9 B1 A8 36 A4 61
on a similar note, modems compress their data before mo-ing it, and
then uncompress it after the dem-ing bit, using lzw under the vbis
standard. all in hardware too! so, compressing packets in this
situation could be a bit redundant.
OT bit:
and while i'm talking about modems, this 'explains' that modem is
infact a program, now in the pubic domain! :-)
Ward Christensen, an IBM systems engineer from Dolton, Ill., coded a
little program he called modem, which enabled computers to send binary
code to one another over phone lines. The difference was that
Christensen released his code to the pubic domain, enabling other
programmers to enhance and perfect a system of checksums and protocols
...
from
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2835949,0...
dr martin.
>on a similar note, modems compress their data before mo-ing it, and
>then uncompress it after the dem-ing bit, using lzw under the vbis
>standard. all in hardware too! so, compressing packets in this
>situation could be a bit redundant.
I would say that networking code is so volatile that you can never
call it 'done', just like AI code (and graphics, less so).
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
I just tried doing a small investigation into this, and failed
miserably in providing any information useful to the discussion.
I did, however invent time travel:
# --- www.von.net ping statistics ---
# 10 packets transmitted, 10 packets received, 0% packet loss
# round-trip min/avg/max = -5819.-4/879.0/6738.2 ms
cool, huh?
--
Gunnar
#31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo: 2
"Det er nok ingen ovn, men fartsm?leren v?r."
Now THAT is good coding ;)
...thanks to everyone who has contributed so far :)
Ash
>> So for the hard tweaks, there should be a difference in biasing your
>> packet size when you know you're sending across a modem, or over LAN
>> (on LAN you must use bigger packets since the header overhead is
>> bigger too).
>I just tried doing a small investigation into this, and failed
>miserably in providing any information useful to the discussion.
>I did, however invent time travel:
># --- www.von.net ping statistics ---
># 10 packets transmitted, 10 packets received, 0% packet loss
># round-trip min/avg/max = -5819.-4/879.0/6738.2 ms
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
> >> So for the hard tweaks, there should be a difference in biasing your
> >> packet size when you know you're sending across a modem, or over LAN
> >> (on LAN you must use bigger packets since the header overhead is
> >> bigger too).
> >I just tried doing a small investigation into this, and failed
> >miserably in providing any information useful to the discussion.
> >I did, however invent time travel:
> ># --- www.von.net ping statistics ---
> ># 10 packets transmitted, 10 packets received, 0% packet loss
> ># round-trip min/avg/max = -5819.-4/879.0/6738.2 ms
> Lol, looks like ping is the best network protocol choice then to avoid
> network lag effects. ;-)
--
Gunnar
#31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo: 2
gnus don't kill people. gnus-summary-lower-score kills people.
>>> Does anyone have any insight?
>>> All the best,
>>> Ash
> I might be wrong, but aren't most packets compressed (or at
> least their data payload) by the ppp networking stack itself?
> PPP is still what most *clients* use, but then again it only
> affects the client itself and the dialin / dsl switch... forget
> it. ;-)
> cheers,
> uwe
Alex
> Alex
uwe
--
Uwe Schuerkamp //////////////////////////// http://www.schuerkamp.de/
Herford, Germany \\\\\\\\\\\\\\\\\\\\\\\\\\ (52.0N/8.5E)
Ever wondered what's wrong with the world? http://bnetwork.com/
PGP Fingerprint: 2E 13 20 22 9A 3F 63 7F 67 6F E9 B1 A8 36 A4 61
