On 11/28/06, Gene Endrody wrote:
>Packet sizes are optimized fairly well....I think. Small
movements
>are filtered out - messages are only sent if there's
substantial
>change. Here's a typical one...
>
>Three of the integer entries are anti-hacker measures,
so it was a
>bit smaller a few months ago. Tankball packets are a
little bigger
>if you're shooting....but not substantialy.
>position message from Sherwood Dungeon
>
>[#errorCode: 0, #recipients: [" DM1"], #senderID: "System.Script",
>#subject: "MP", #content: [10800, 749, 7796,
200, 75, 4, 9929810,
>"1011001", "sd", 8429716, 1794369],
#timeStamp: 9929817]
>
>Gene
Ah.
In my case I was thinking of some proxy stuff to compress
packets,
but even with regular MUS stuff you could reduce this quite
a bit:
1) reduce length of symbol names
2) Base64 encode numbers
3) Pack the "Content" field into a single string
This will require additional processing on both ends of the
transaction, but you could reduce your above example to:
[#e: 0, #r: ["DM1"], #sid:
"System.Script", #s: "MP", #c:
"Cow Lt
B50 DI BL 4 l4RS 1011001 sd gKCU
G2FB", #ts: "l4RZ"]
without having to completely restucture your code.
Depending on how your server CPU load is, you could even
compact
further and add a checksum.
I generally just have two fields: packet type and packet
contents as
a string. Of course, I've never tried anything on the scale
you're
dealing with.
189 bytes becomes 119 bytes.
If you're running 1800 gB/month, that's a savings of 667gB
per month.
If the additional overhead of taking the packets apart
doesn't kill
the server, that's a significant savings.
--
. . . . . . . . . . . . . . . . . . . . . . . .
Lon Koenig Consulting lonmediagods.com
(612) 965-6305 http://www.schnoggo.com
_______________________________________________
dirGames-L mailing list - dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l
|