Re: [CODE] Stuck with recieving data from descriptor....

From: Daniel A. Koepke (
Date: 06/15/01

On Fri, 15 Jun 2001, Pure Krome wrote:

> I need to know if a some text sent from the game to my client is PART
> of a number of packets. Ie. i suppose i need to apply packet numbering
> at the start of each packet sent?

There are many ways to determine if a single packet is part of a whole
that was split.  I could go into them here, but there's a better solution
to your problem:

Don't care.

You see, you've gotten a bit wrapped up in the wrong thinking.  There's no
reason to know if some text belongs to a whole.  XML is structured with
starting and ending tags -- meaning, you can always tell the start and end
of a block of XML.

Consider the text

  <obj type="sword">Blade of Bad Stuff</obj>

if it were split, conveniently,

  #1:  <obj type="sword">
  #2:  Blade of Bad Stuff
  #3:  </obj>

First things first: we receive packet #1, which contains the complete
opening tag.  We know it contains the complete opening tag because there's
the opening and ending angle brackets (<>).  So we parse this XML, see
that it may contain a body (because it's not of the form <.../>), and push
a "scope" (or "block" or what-have-you) to store the body in.  We then
read packet #2 and buffer it in the block.  We get to packet #3, and then
write out our buffered text with whatever necessary formatting (either to
the screen or to the enclosing scope, if there is one).

What happens if the split is less convenient?

  #1:  <obj t
  #2:  ype="sword"
  #3:  >
  #4:  Blade of Bad Stuff
  #5:  <
  #6:  /obj>

There are a few challenges offered up, here.  When we receive packet #1,
we don't know enough about our code to determine what to do with it -- all
we know is that it's not a complete XML code (there's no terminating '>').
So we buffer the text.  We get packet #2 and see that we still don't have
enough information to determine the type of the XML code (that can only be
determined conclusively when we reach the end: if it's "/>" then it's an
empty-body tag, and if it's ">" it may have a body).  So we tack #2 onto
the end of the buffer.  Finally, we get to #3 and see the terminating '>'.
We tack that onto the end of the buffer and then parse the entire XML
code, adding a scope as with before.  #4 is read into that scope, same as
before, and we move onto #5.

#5 is tricky because our first instinct when we encounter what looks like
the beginning of an XML tag might be to allocate memory for the tag,
perhaps the body of the tag, and then switch into a state looking for the
terminating tag.  We can see that if we did this, here, we would mess up
because we actually have a closing tag, but the leading '/' was split into
the next packet.  We take the same approach we did with packets #1-3:
instead of trying to parse them immediately upon arrival, we buffer them
until we get the terminator (i.e., the entire code), then parse.  We get
the end of the scope, close it down, and proceed as with the first, more
convenient, case.

One benefit of XML is that it's a well-defined language and parsing it is
simple.  We read a bare '<' and we know that some XML tag is following.
This tag will always end with '>'.  Inside, we know the first word is the
name of the tag.  If there's a space following that and then another word,
it's an attribute, which must be followed by the sequence '=', '"', some
text, '"'.

Anyway, the key to being able to parse XML data that is potentially split
over packets is to just recognize that the data is well-structured and
well-defined.  The only time you should need packet numbering schemes is
when you're using a protocol that doesn't guarantee the transmission order
of the data.

Daniel A. Koepke (dak),
Caveat emptor: I say what I mean and mean what I say.  Listen well.
Caveat venditor: Say what you mean, mean what you say.  Say it well.

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/05/01 PST