Show EQ Packet Format Query

[Slinky]

I've been looking at the EQ packet format code, and I've got a couple of questions so if anyone is able to bare with me and answer them I'd be grateful.

My questions centre around the way split packets are handled.

I (think I) understand the ARQ semantics, and how this facilitates both ordered packet processing and resend request for missing 'guaranteed' packets but I have a couple of questions :

a) Do the sequence numbers reset after every ordered sequence?

- Hmm on further inspection it appears that sequence resets on zoning.

b) I ask because otherwise I don't see the necessity for the seqStart/seqEnd flags. It seems to me that one could detect missing packets by interogating the payload type from the packet and realising more data has to follow. Even if the initial packet, with the payload type info in it, was to go astray, this would be apparent from the gap in the sequence numbers surely?

EDIT :

Also some of the flags aren't too obvious to me, what is the purpose of the following: (I've commented the ones I think I know)

ARQ - Ack Request
ASQ - Sequence number in packet.
ClosingLo/ClosingHi - ?
SeqStart/SeqEnd/Fragment - Beginning, middle or end of split payload packets (i.e. fragmented payload).
ARSP - Ack Response
SpecArq - ?

I think maybe I'm confusing ARQ and ASQ?

[fee]

The flags tell what kinda of attributtes to expect in the packet. For instance;

is it sequenced (does it matter what order it arrives)
does it contain acknowledgment or request info
is it a fragment(should we expect more parts before processing)
Is it the beginning of a session or an end

The best thing to do is sit down with some packet capture and start looking at the first 2 to 16 bytes. You should very quickly see the pattern. Draw out a diagram of the flags and see how each packet fits into it and how it is processed in the code.

To answer a couple of your questions. There are actually 2 sets of sequences found, the first one is seen in both ARQ and non-ARQ packets, and the other is seen in ARQ only packets. Since ARQ packets are the important ones, we only use this sequence number. If the packet is non-ARQ then we just process it as it comes in. The ARQ sequence also starts at a random value, this is why it is important to catch SEQStart/ASQ/ARQ packets. The ARQ sequence is only 16bits large so it is possible to see this value wrap around many times depending on the amount of time you spend in a zone. (hint: all data packets contain ASQ)

Your assumption in "b)" is false. Generally multipart packets contain variable length data, such as item info and zone spawns. Its simply efficient to use the eqpacket header information to piece these multipart packets together.

The current incarnation of the packet processor was architected by myself and Zaphod. I don't think you will ever see a better passive packet processing engine. This is defintly a segment of code worth learning and understanding if you are into this sort of thing.

[Slinky]

Thanks for the response!

Ok, so the seqStart, seqEnd have nothing to do with the fragment flag. They just indicate that the arq on the message is the start or end sequence number.

I'm still not quite clear what ASQ indicates?

Also does an ARSP get sent back for every ARQ packet, or does it just use the selective repeat mechanism of re-requesting only if it detects a packet missing?

I've not had a chance to look at it running live as I'm looking at the code from work, and trying to reconcile it with what I know of TCP/ARQ mechanisms. The codes very clear, but being a filter and not having to act on some of the information on the packets makes it a little harder for me to infer what exactly is going on, so I definitely appreciate any info you have time to provide.

I'm mostly trying to study how games build their UDP stacks as its something I find very interesting.

[fee]

I can see how studing showeq is confusing you. Showeq's packet processor was designed to be light-weight and fast. It only processes the data it has to. If you really want to learn the EQ protocol, I recomend two approaches. First take the basic knowledge you have gained from reading the showeq source and apply it to what you see in packet capture. Secondly, go check out the source code for the emulators, both EthernalQuest and the other one at eqemu.sf.net The emulators implement the protocol in its entirety.

Good Luck
fee

[Slinky]

Thanks for all the help, thats a damned fine idea.