Even though the packet buffer aspect of bnet dev is pretty simple for the experienced guys here, i have noticed that there seems to be a few different ways to approach it.

The first I've noticed is with byte shifting, and "padding", using stuff like RtlZeroMemory and stuff, it seemed pretty simple, I lost the code though.

The other which seems a bit more complicated is using a huge chunk of data and just using a buffer variable to copy the data of what you are trying to add, to the address of the location you are currently at in the packet.

Why are their different ways to do it, which is the most straightforward (easier to understand, to the point, etc.), and what is the most popular way of going about making this class (in-case there is some method I haven't seen yet)?

RtlMoveMemory, not Zero. And see the link in my sig for an example of that way (in vb6), which I deem the best.

What language do you plan to write it in? If it's any .NET language, you can use a MemoryStream and BitConverter (which is what I'd do), otherwise, you would have to use a string or a byte array, which isn't as simple as stream.write(). :(

[quote author=Pyro link=topic=17645.msg179744#msg179744 date=1220914490]
What language do you plan to write it in? If it's any .NET language, you can use a MemoryStream and BitConverter (which is what I'd do), otherwise, you would have to use a string or a byte array, which isn't as simple as stream.write(). :(
[/quote]
That's true.  I've been trying to decide if there's a better way to do it - not actuall normalize all the pieces into a packet until it's about to be sent and things like that.

I could see a packet buffer class that used templates/factory pattern to create classes for each packet.  This would be an interesting proof of concept for a highly OO language.  Would code generation be better? I might play with this later and post my results

[quote author=c0ol link=topic=17645.msg179759#msg179759 date=1221064611]
I could see a packet buffer class that used templates/factory pattern to create classes for each packet.  This would be an interesting proof of concept for a highly OO language.  Would code generation be better? I might play with this later and post my results
[/quote]

I don't think code generation is appropriate in this case; while the commonality is high enough for generation to be feasible, the fact is that you're still going to have to write the code to read from the generated classes, and that code will be equivalent in size and effort to reading from the buffer. It just doesn't make sense to have 80 different classes that all do the same thing. Single-responsibility is important, but reuse is also important, so skip the middle man and just work directly on a stream-like object, providing methods like readDWord().

I use a decorated InputStream and OuputStream in Java as a base for my packet buffers.

[quote author=Camel link=topic=17645.msg179760#msg179760 date=1221067089]
[quote author=c0ol link=topic=17645.msg179759#msg179759 date=1221064611]
I could see a packet buffer class that used templates/factory pattern to create classes for each packet.  This would be an interesting proof of concept for a highly OO language.  Would code generation be better? I might play with this later and post my results
[/quote]

I don't think code generation is appropriate in this case; while the commonality is high enough for generation to be feasible, the fact is that you're still going to have to write the code to read from the generated classes, and that code will be equivalent in size and effort to reading from the buffer. It just doesn't make sense to have 80 different classes that all do the same thing. Single-responsibility is important, but reuse is also important, so skip the middle man and just work directly on a stream-like object, providing methods like readDWord().

I use a decorated InputStream and OuputStream in Java as a base for my packet buffers.
[/quote]
I agree with Camel here; I've personally never seen a lot of value in creating classes for each packet, preferring to take a stream-like approach and deal with the information out of that as higher-level objects.  Each individual packet is a fairly low-level object, and with eighty or so of them, you have to consider the complexity and information management that will add to your project.

You should also consider the problem domain.  A Packet is an object within your problem domain, as is something like a ChannelUser.  A ChannelUser is communicated to your client via a Packet; now, you could have a UserJoinedPacket that contains the properties of the user.  That presents some questions:

* If there is a UserJoined packet, does that make the ChannelUser object pointless?
* What does a UserJoinedPacket mean as opposed to a ChannelUser?

For me, I tend to think of the ChannelUser as an entity that exists apart from the Packet and is communicated by a Packet.  This degree of separation permits me to think of the user as a distinct entity from the communication medium, which could permit later flexibility (for example, a ChannelUser would exist in an AIM and MSN environment, as well, although they might mean something different).

Code generation might be a worthwhile approach, but also has limitations in that you still need to regenerate and potentially interact with generated code differently if they change something.

It's all about how you want to do your domain analysis.