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), dkoepke@circlemud.org 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: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST