BitStream breaking byte!

Howdy,

im using a bitstream for my MMORPG. So, then i found out how do i break packets?
My choice is to use an INT(2147483647), in HEX: FFFFFF7F.
This value will never be reached in my game in any way.
Im still searching for complications. For example, if one where to type ÿÿÿ?, it would break. But i can filter on this to not allow such a combination to send. It is not the end-user end im concerned about, but rather my own bitstream.
Example: I send X,Y,Speed,Angle. Now, if for SOME RARE reason, this would be 255,255,255,127, it would break up. Altough.. thats not true, because i would send it like this: Type,Size,Value, and the size is only specified if it where a string or file. So, Type1=byte=1 in size. Actualy, my packet would look like 1.255.1.255.1.255.1.127 instead.
So, if i where to have a Type2 = short + Type5= float, im going to get troubles... i guess: 2.5525.5.255127
But that is the ASCII presentation, so it would be different in bytes. Ugh... im lost. *graps hexeditor yet again*

Meenwhile, Any comments?

oh sheesh... a type identifier would then be FF=255, so that doesnt exists. k. i guess thats solved then. Using FFFFFF7F as breaking value for TCP bitstream, works.

Why do you need a delimiter? Why not just know what the data represents and what size it is supposed to be?

Because a hacker can modify the package and cause your server to read its self to death basicly..

Any data you send should be encapsulated, surely? Just dumping raw data through a stream is asking for trouble, as you've found out!

An example stream could be formatted thus:-

$F0FFFF0F to signify "following 16bit value will identify the type of data being sent"
$0001 (packet type, i.e "positional data")
$000C (number of bytes of information in this packet)
$0000010A (X)
$00000030 (Y)
$001A (Speed)
$00F5 (Angle)
[Next packet]

You'd need to define packet types for every type of data you'd need to send, such as: text (for chatting), time sync, text (for system notices or announcements)...

Just a thought ;)

It wouldn't keep reading if the server knew how long the packet is supposed to be, ie don't send the length within the packet itself.

Packet sizes could change between different versions of the client. The server would need updating or it would read X number of bytes for the packet and then assume the next byte is the next packet, which may nto be the case.

Supplying the packet size from the client lets the server either ignore extraneous data or report back to the client with a "packet size different than expected" flag. The client could then choose to either halt with an error "server problem" (or something more descriptive) or to warn and continue with "some features not supported by this server".

I'm assuming that the server would have already identified its version during the initial connection, but at least this guards the server from malicious clients and also somewhat against genuine connection errors.

Malicious clients could still forge invalid packets of arbitrary length, but sanity checking by the server could eliminate any undesired activity resulting from this.

Defensive coding :)

Not to mention that a textbased packet (chat) always needs an extensive length. If a hacker finds out, he could still flood the server by sending less data, so the data of a new packet would be read as if it where part of the chat, cause the packet to slipt up and well, from there on you can figure what will happen...

p.s. whats te $F0FFFF0F for? if it would change it cant be used as a delimiter. Thats why i picked $FFFFFF0F.

Goldstar: $F0FFFF0F for some half-remembered reason that I was going to try and fully remember but couldn't. I'm sure there's a good and logical why it's a good idea but I'll be darned if I know why.

i guess it makes the combination less common?

as FFFFFF0F could more accidently occure then F0FFFF0F ? that it?

No, that wasn't it. I think I'm mis-remembering it as applied to networking techniques. It's probably just me going quietly senile.

It's been a long time since I coded anything that involved networking and I've never used Blitz networking.

I just know that you have to code very defensively when doing client-server comms, especially when you can't trust the client.

**EDIT**

If I were less tired and had time this weekend to sit with the laptop I'd come up with something bulletproof. Sadly, I have a girlfriend (not inflatable) and I'm going to be quite busy for a while. Shopping etc. You know how it goes :-/

LOL

You should post Blitz programming related questions in the relevant forum instead of General Discussion.

I cant move the topic...

I didn't mean for you to move it - I meant for you to put it in the right forum in the first place. ;)