Variable Length Packets to Class (efficiently)

[dequadin]

<snip>

 

[davemc]

Most translate-able method:
Convert variable data to Base64 encoded string. Send string. Un-convert from Base64 on the other side.

Otherwise ISerializable is plenty good enough.

I would just TCP-Connect and send the raw data-stream direct. I hate all these add-on and slowdown classes.

 

[Lazy]

It's a pitty I only came onto this thread now, I could have saved you a good few hours there, hehe.

I was really wondering as to why you were dabbling with GCHandle in the first place...

 

[Lazy]

Umm okay What would you have suggested?

Nothing radically different to what you did in the end. What I meant was, you asked here for help and this sort of thing is right up my ally, so two minds are better than one mind. Therefore it could have saved a bit of time

 

[Lazy]

Cool thanks

The first method I used for a protocol I wrote myself. Storing the packet structure in a struct and then doing a "Managed Memcopy" - for want of better words - works well. Because when I was developing the protocol, I could just move/add/whatever the fields in the stuct and my Serialization/DeSerialization to send it off via a socket never needed updating. *But* this packet structure never changed in length.

Obviously this won't work for a variable length packet. I think the having lots of byte[]'s for each field and then encapsulating them into the class properties is a good method. Buffer.BlockCopy is kick-ass, I never knew about it originally...

When I get a chance I'm going to benchmark these against each other, in terms of execution time. I'm not concerned with memory usage.

I usually use Array.Copy and haven't compared it to Buffer.BlockCopy yet. I almost always use BitConverter and similar methods to what you are using. I've built systems that can do in excess of 1000 TPS using this method and memory has never been a problem.

I have done comparisons between [for example] declaring ArrayLists.Add with creating a buffer and manually Array.Copy'ing the data across and found Array.Copy to be so much faster that it's almost silly NOT to do it, hehe.

I also [nearly always at least] declare structure's for my protocols too, it makes it so much easier to incorporate your protocol into an OO application, or to just work with the protocol (and to unit test it). It also makes secure fields a little easier since you can incorporate the security into your structure, thus making it [nearly] transparent.

 

[Lazy]

From what I've read online Buffer.BlockCopy is used for arrays of native type (int, byte, short etc) where as Array.Copy you can use on any type.

The big differences are that Array.Copy will do Boxing/UnBoxing on native types (which affects performance) and Buffer.BlockCopy doesn't do this. The other is that in Array.Copy uses array indexes where as Buffer.BlockCopy uses byte offsets.

ArrayList.Add also does boxing/unboxing on native types, rather use a generic List<>, this again doesn't do this.

I'll definately mess about with the Buffer.BlockCopy now, thanks. Yeah there's not much point using ArrayLists after generics were introduced, if for no other reason than it simply makes your code a lot easier to read too, hehe.

In terms of performance, you don't really want to use any dynamic collection unless you can initialize it to a good estimated size right at the outset [for what we are doing here at least]. If you can't, Array.Copy/Buffer.BlockCopy will beat it's performance hands down...