SIMWRITITNG : Networking compression?

Hi Folks, 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 gaming? 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

On Thu, 10 Jan 2002 12:03:54 +0000, Ashley McConnell <[email hidden]> wrote:

Quoted text (9 lines)

>Hi Folks, > >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 gaming? > >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.

I would think so too, yes. However, on game *servers* with high bandwidths this may not be that good of an idea (20 players sending compressed packets to the server, which all have to be uncompressed). 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.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Not sure how sims do it, but the better FPS games out there use a form of compression, and send it in a bit stream rather than a byte stream. The "compression" however is I think not a true compression algorithm. It's referred to as delta compression, which as I understand it means that they only send a full positional update for an entity when it is spawned, and then after that send the change in position instead, the idea being that in a bit stream the smaller number needed for a delta takes up less space. This works as long as there is no packet loss. In the event of packet loss you would have to have some protocol to request the full positional update again in order to synch the client and server back up. Some of them also send the positional information at a reduced resolution, but I doubt that would be a good idea in a sim. "Ashley McConnell" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (7 lines)

> Hi Folks, > > 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 gaming? > > I would have thought that as the speed of pc's increase and increase

the

Quoted text (8 lines)

> 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 >

If Im not mistaken, compressing packets is bad No matter how great a server you ultimately require, the easier the server can read the data, the more users you can imploy Thats probably more important than overall bandwidth since it allows you more flexibility when it comes to enhamcements 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 Ashley McConnell <[email hidden]> wrote in message news:[email hidden]... > Hi Folks, > > 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 gaming? > > 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 >

Ashley McConnell <[email hidden]> wrote in news:[email hidden]:

Quoted text (15 lines)

> Hi Folks, > > 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 gaming? > > 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 >

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.

> Ashley McConnell <[email hidden]> wrote in >> >> 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 -- 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

> 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. ;-) 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,00.html dr martin.

On Fri, 11 Jan 2002 09:55:25 GMT, [email hidden] wrote:

Quoted text (10 lines)

>> 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. ;-) > >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.

That's a good argument, although I don't think LAN packets are compressed. As I understand it, PPP is modem-only. In fact, PPP UDP packet headers are compressed, while LAN UDP packets are not. With PPP, you get 5 bytes of header, and your data ofcourse. On LAN, this compression was never deemed necessary and this results in 28 bytes headers (20 bytes IP, 8 bytes UDP). 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 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/

[email hidden] (Ruud van Gaal) writes: > 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 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."

Lol, nice one :) Now THAT is good coding ;) ...thanks to everyone who has contributed so far :) Ash

Quoted text (10 lines)

> 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? > >

On 11 Jan 2002 14:36:27 +0100, Gunnar Horrigmo <[email hidden]> wrote:

Quoted text (15 lines)

>[email hidden] (Ruud van Gaal) writes: > >> 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. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

[email hidden] (Ruud van Gaal) writes:

Quoted text (20 lines)

> On 11 Jan 2002 14:36:27 +0100, Gunnar Horrigmo <[email hidden]> > wrote: > >[email hidden] (Ruud van Gaal) writes: > > > >> 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. ;-)

nah. that would make all your fellow competitors run backwards and lead to papy yanking everyone's CD keys. :) -- 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.

Uwe Schuerkamp <[email hidden]> wrote in news:[email hidden]:

Quoted text (17 lines)

>> Ashley McConnell <[email hidden]> wrote in >>> >>> 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

Hmm... I didn't consider anybody may want to send packets through PPP ;> Alex

On Fri, 11 Jan 2002 23:49:08 GMT, alexti <[email hidden]> wrote: > Hmm... I didn't consider anybody may want to send packets > through PPP ;> > > Alex ;-) That's why I said "forget it", because the modem uses PPP, you know ;-) 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