On 2006/09/19, at 13:35, John Hurliman wrote:
The code generation is actual a lot closer to reality now, axial
has been doing a fair bit of work on it. By pre-generating all the
code it should remove the need for the external keywords.txt/
message_template.msg to be shipped with applications, and it
produces code optimized for each packet (without the overhead of
reflection). The other side of this is an optional update server
that produces the latest stable libsecondlife.dll (updated after
every message_template.msg update) for client apps to take
advantage of. The details can be hashed out some more in a separate
thread since this is a big change.
That's me. For those who haven't been following all of the
discussion, I'll summarize the idea. First of all, what I mean by
"protocol code" is just the low-level stuff responsible for
converting back and forth between the UDP packets we use the
communicate with SL and the Packet objects we use internally in libsl.
As I'm sure you're all aware, we're currently representing packets in
libsl as hashtables of hashtables of fields. Every time libsl
starts, it reads in the keywords.txt and message_template.msg files
and builds up a huge internal data structure representing what types
of packets are available and how they're structured. Whenever libsl
sends or receives a packet, it digs into that data structure to
figure out which fields in which hashtables correspond to which
bytes. It works fine, but there's a few problems:
- It makes it easy for developers using libsl to make mistakes. If
you give libsl a short when it wanted an int, you don't know about it
until you get a (rather confusing) error at runtime. It'd be nice to
get those errors at compile time.
- It's not terribly fast, since there's a lot of runtime reflection
going on. The protocol code is pretty fundamental, so it'd be nice
if it didn't have to go through all those steps every time it sees a
packet.
- You have to ship keywords.txt and message_template.msg along with
every libsl app, and the app will error out (violently) if it's not
run from the same directory as those files. It'd be nice to just
build everything into the .dll.
- It's a bit buggy. Packets are getting truncated and endianness
bugs keep popping up over and over. It'd be nice if we could go back
and redo the delicate parts, knowing now where we have to be more
careful.
So I've been working on a fresh implementation of the protocol code
that addresses these four issues. The general idea is that, instead
of reflecting on the keywords/message_template data at runtime, we
write a tool that turns those two files into a bunch of C# classes--
one for each type of packet. The blocks and fields will just be
normal object properties. If you wanted to make a ChatFromViewer
packet, it'd look something like this:
ChatFromViewerPacket p = new ChatFromViewerPacket();
p.AgentData.AgentID = myAgentID;
p.AgentData.SessionID = mySessionID;
p.ChatData.Message = "hello, simulator"
p.ChatData.Type = 1;
p.ChatData.Channel = 0;
And that's it. Since the fields are normal object properties, you'll
get an error at compile time if you try to stick a vector where it
wanted a quaternion. The ChatFromViewerPacket class knows how to
turn itself into a UDP packet, and it knows how to construct itself
from a UDP packet. It should be faster than the old method, and
since it's a class that's compiled into the dll, you won't need to
keep the keywords/message_protocol files around anymore. There's a
couple other bonuses too; for example, you'll get auto-completion on
packet and field names in any IDE that supports it.
Of course, it's not done yet. I wrote the easy parts, but I've been
a bit too busy to dive into the tricky bits (namely, all the stuff
that wound up bug-ridden the first time around). Once it is working,
I'll merge it in alongside the current protocol implementation--at
first you'll be able to use whichever one you want (that'd be a lot
of code to rewrite if I forced it on you overnight)--and if people
like it, we'll phase out the old code. At least, that's the plan in
a nutshell.
-- Era Pixel
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
