A different type of packet...

[Ricky26]

I seem to have a problem... The packets in Hostile Space contain more than one command...

i.e.

packet
{
command { type, length, data }
command { type, length, data }
...
} // This is make-believe script.. xD

or for Hex ppl

0x02 0x02 0xDA 0xTA 0x02 0x02 0xDA 0xTA

But RunUO just ditches the commands other than the first, can someone, PLEASE help me. Im very lost at whats goin on...

Ricky26,

[Serp]

TCP guarantees that your data will arrive on the other side in the same order that you sent it, and that all data will actually arrive. The data is delivered as a stream, not individual packets. Let's say you receive the sequence
0x02 0x02 0xDA 0xTA 0x02 0x02 0xDA 0xTA
Now it's up to you to parse this.
The number of bytes received is >= 1, so you can get the packet identifier. In this case, it is 0x02. You know that this packet is of dynamic length (either by using a lookup table, or just having the protocol guarantee you that all packets are of dynamic length). If the number of received bytes is >= 2, you can read the next byte and get the length of the data. The length of the data in this case is 0x02. If the number of received bytes is >= 2+0x02, then you can extract the packet from your receive buffer and handle it.
After you've handled it you go back to the receive buffer and see if you have enough data to handle the next packet and if you don't wait for more data to arrive before checking again.
RunUO does all this, so unless you removed too much in your modifications, it will still be there.
If you're making your own network handling code, I advise you to make use of RunUO's ByteQueue. It's proven very useful for me in the past for keeping track of the number of received bytes, the next buffered packet's identifier etc :-)

[Ricky26]

I know about TCP streams ^_^. But RunUO seems to be parsing the first command and not the second... The second being the logon command, which means the game doesnt load....

Aha! Ive found something that may be of use...

In MessagePump.Slice(), the queue doesnt contain the second command, allthough the Netstate buffer does...

EDIT: Sorry about the previous post, I was kinda tired and angry...

[Ricky26]

Any ideas? Because I'm not looking forward to re-coding the RunUO packet system...

Detail:

RunUO receives two packets..

It adds the stream to the queue.

Stream is dequeued.

First packet is parsed.

Second packet is released.. (Not good...)

[Ricky26]

It seems windows doesnt like it when packets end with 0s.

Example:

0x76 0x08 0x00 0x1c 0x00 0x00 0x00 0x00 0x00 0x00

would be truncated to 0x76 0x08 0x00 0x1c

and then the next packet would add on at the end... Not only invalidating that packet, but practically all the once afterwards....

E.G.

0x76 0x08 0x00 0x1c 0x02 0x06 0xDA 0xTA 0xDA 0xTA 0xDA 0xTA

(DA is not a valid packet type, and TA isnt a valid length...)

Minor h4x0r1ng fixed this... Im sorry I ever blamed you... *hugs runUO*

*gets cane to beat microsoft*