This is a great topic, a very interesting read even though
I've never used
MUS.
Regarding the #content, does MUS require it be a list, or
could you send a
string if you wanted?
On 11/28/06, Gene Endrody <gene mmorpg.ca> wrote:
>
> Actually I worked it out because I was curious myself.
I've changed my
> mind
> about the SMUS being inefficient. The message I
provided is 106 bytes.
>
> for my message....
>
> [#errorCode: 0, #recipients: ["DM1"], #senderID: "System.Script",
> #subject:
> "MP", #content: [10800, 749, 7796, 200, 75,
4, 9929810, "1011001", "sd",
> 8429716, 1794369], #timeStamp: 9929817]
>
> Here's the math......
>
> header 16 bytes
> errorcode 4 bytes
> recipients 8 bytes
> senderid 18 bytes
> Subject 6 bytes
> Timestamp 4 bytes
> Content -
> 9x4 integers=36 bytes, "1011001"=12 bytes,
"sd"=6 bytes.....50bytes total
> for content
>
> so 16+4+8+18+6+4+50=106 bytes
>
> Gene
> MaidMarian.com
>
> ----- Original Message -----
> From: "Lon Koenig" <lonmediagods.com>
> To: "Director - Shockwave - and Flash Game
Production"
> <dirgames-lnuttybar.drama.uga.edu>
> Sent: Tuesday, November 28, 2006 11:59 AM
> Subject: Re: [dirGames-L] Multiuser - ballpark figures?
>
>
> > 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
> >
>
>
> _______________________________________________
> dirGames-L mailing list - dirGames-Lnuttybar.drama.uga.edu
> http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l
>
_______________________________________________
dirGames-L mailing list - dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l
|