I did a quick packet statistics for one race (cca. 10 players) on AA Blackwood GTI with all default Airio settings.
Here are the flags my insim use:
ISF_LOCAL | ISF_MSO_COLS | ISF_HLV | ISF_OBH | ISF_CON | ISF_AXM_LOAD | ISF_AXM_EDIT | ISF_MCI /*UDP (not counted)*/

Total sizes per each packet type:

Quote :

Packet type 3 (ISP_TINY) - 64 bytes
Packet type 5 (ISP_STA) - 728 bytes
Packet type 11 (ISP_MSO) - 32096 bytes
Packet type 18 (ISP_NCN) - 336 bytes
Packet type 19 (ISP_CNL) - 32 bytes
Packet type 21 (ISP_NPL) - 456 bytes
Packet type 22 (ISP_PLP) - 4 bytes
Packet type 23 (ISP_PLL) - 20 bytes
Packet type 24 (ISP_LAP) - 540 bytes
Packet type 25 (ISP_SPX) - 976 bytes
Packet type 28 (ISP_PLA) - 72 bytes
Packet type 29 (ISP_CCH) - 32 bytes
Packet type 32 (ISP_FLG) - 280 bytes
Packet type 34 (ISP_FIN) - 140 bytes
Packet type 35 (ISP_RES) - 588 bytes
Packet type 50 (ISP_CON) - 200 bytes
Packet type 51 (ISP_OBH) - 216 bytes
Packet type 52 (ISP_HLV) - 608 bytes
___________________________
Total: 37388 bytes

At the same time I was logging how much bytes it would be if it used variable size IS_MSO based on message length.
IS_MSO dropped from initial 32096 to 13628 bytes, which makes total size of all packets 18920. That is roughly about twice lower, so I believe there is a good reason to consider this suggestion.

Also other text packet from Insim to LFS like IS_MSL, IS_MST, IS_MSX could use it too, but that isn't such a priority.
Idea came from thing that at the moment IS_BTN accept variable size packets, and when I tried to use a full lenght my menus completly lost all the fluidity.

Did you include the requisite for padding up to a length that is divisible by 4 on the packet length by padding the text field? Although a drop by over 50% is impressive is there a situation where this is needed, edge connections running an InSim client?

I guess my point is, does it add unnecessary complexity to the packet parser for no real world benefit.

[Edit] I guess from a parser standpoint, having all of the Text and Msg fields parsed by the same bit of code would be a nice homogenization from a code stand point.

Quote from Dygear :

Did you include the requisite for padding up to a length that is divisible by 4 on the packet length by padding the text field?

Of course

Quote from Dygear :

I guess my point is, does it add unnecessary complexity to the packet parser for no real world benefit.

Every insim which is written by the specification of InSim (TCP) will handle it with no problems.
First byte of every insim packet is Size (Header), so you should simply always remove Size number of bytes from buffer.
In my opinion there isn't even 'c' of complexity ...

Quote from DANIEL-CRO :

Quote from Dygear :

I guess my point is, does it add unnecessary complexity to the packet parser for no real world benefit.

Every insim which is written by the specification of InSim (TCP) will handle it with no problems.
First byte of every insim packet is Size (Header), so you should simply always remove Size number of bytes from buffer.
In my opinion there isn't even 'c' of complexity ...

In PRISM we peek a headers first, then read the packet based off the header's signature. There are currently two types of string parsers in the PRISM code base that handle packing and unpacking of the string into the packet because of how they are handled when it comes to packet length requirements and NULL termination vs no NULL termination. Anything that brings that code base down into a more generic form is better for me as it would be able to handle it in a single master class that could be inherited too the other packet classes.

That's the verbose way of saying, +1, I'm for it. But I wonder if other programming languages would be benefited or not from this?

i need insim with 0.6G

Quote from bekacercvaze :

i need insim with 0.6G

Program one yourself, or keep building on those that exist.