MaxPacketDataSize
by Sam Redfern · in Torque Game Engine · 03/08/2005 (4:26 am) · 4 replies
Hi,
I've currently working on a desktop-sharing application similar to what NetMeeting does, with (obviously!) the images being rendered into a texture within Torque.
I've got a block-update approach working so that only sections of the bitmap that have changed are updated. Working within the standard 1500 byte limit per-packet makes the whole thing run a bit slow and it forces me to use very small blocks (20x20 pixels packed as a png). I have changed MaxPacketDataSize to 15000 in engine/platform/event.h, and this seems to help a lot, i.e. allows me to safely work with blocks of about 60x60 pixels.
My question is: is anyone aware of any negative side effects of doing this? -- the 1500 byte limit must have been put there for a reason..?
I've currently working on a desktop-sharing application similar to what NetMeeting does, with (obviously!) the images being rendered into a texture within Torque.
I've got a block-update approach working so that only sections of the bitmap that have changed are updated. Working within the standard 1500 byte limit per-packet makes the whole thing run a bit slow and it forces me to use very small blocks (20x20 pixels packed as a png). I have changed MaxPacketDataSize to 15000 in engine/platform/event.h, and this seems to help a lot, i.e. allows me to safely work with blocks of about 60x60 pixels.
My question is: is anyone aware of any negative side effects of doing this? -- the 1500 byte limit must have been put there for a reason..?
About the author
#2
03/14/2005 (5:55 pm)
For that sort of application (where you have a broad data stream) you probably want to increase the packet rate as well as the size - though 15,000 is probably going to be prone to fragmentation/truncation problems. The packet rate by default is something like ten - you could probably bump it up to thirty or so without problems on a LAN.
#3
Interesting side note: I read one of the GDC presentation summaries on GamaSutra that discussed a "new technology" that was designed to allow 10,000+ players on a single game server, yadda yadda yadda.
What was interesting to me is that their primary concept was to minimize packet fragmentation by limiting packet size. Unless they are talking something wildly different (and they did have some marketing speak about handling restringing and packet resend needs at a separate layer, I'll admit), that's the entire purpose of keeping your MaxPacketSize below the median to bottom MTU for your market's eth cards. It used to be that some cards would break packets up above 550 bytes, but by now I would imagine those are very few and very far in between, but in any case, simply jacking up MaxPacketSize is not nearly the benefit you'd think, since you are actually adding additional processing time during breakup and restringing--in some cases, restringing a packet that big is going to cause you more performance loss than you would imagine.
03/14/2005 (6:18 pm)
Heh..I was about to post exactly what David and Ben did when I saw the title of this post, but they beat me to it!Interesting side note: I read one of the GDC presentation summaries on GamaSutra that discussed a "new technology" that was designed to allow 10,000+ players on a single game server, yadda yadda yadda.
What was interesting to me is that their primary concept was to minimize packet fragmentation by limiting packet size. Unless they are talking something wildly different (and they did have some marketing speak about handling restringing and packet resend needs at a separate layer, I'll admit), that's the entire purpose of keeping your MaxPacketSize below the median to bottom MTU for your market's eth cards. It used to be that some cards would break packets up above 550 bytes, but by now I would imagine those are very few and very far in between, but in any case, simply jacking up MaxPacketSize is not nearly the benefit you'd think, since you are actually adding additional processing time during breakup and restringing--in some cases, restringing a packet that big is going to cause you more performance loss than you would imagine.
#4
03/16/2005 (5:56 am)
Thanks for the info. guys... I'll give a go at reducing it back to 1500 and sending my 20x20 pngs at a faster rate... 
Torque Owner David Hinson
You say raising it to 15,000 "seems to help a lot". Hmm. Ok, if you know that to be true. But also know that you are causing a lot of network packet fragmentation and reassembly if you are transmitting messages that large which is not desirable.