If your looking at serializers and network protocols, using a binary
serializer with tcp is the fastest. If you have .NET on both sides (i.e.
CLR), then using Remoting with binary serializer and tcp would be a good
method. If you don't have CLR on both sides or you have a need for other
systems to communicate with your server and clients, then xml would be a
good choice (until Indigo in 2005 timeframe.) XML could be an option as you
get a serializer for your class(es) and structs and don't have to create
your own. However, that comes at a cost of performance. Depending on your
data, XML can increase the size of your stream by many factors and you have
the cost of serialize and deserilize on both sides in a two way
conversation. This may be ok for your needs. You would have to run perf
tests to see. I would probably go with Remoting first (as easy to prototype
and test perf), and if need more perf, then go something like
Marshal.StructToPtr and Marshal.PtrToStruct to serialize yourself and pass
byte[]s around over sockets (I don't think this will save much in perf and
will harder to program and support). Just some thoughts. Cheers!
--
William Stacey, MS MVP
TT (Tom Tempelaere) said:
William,
Honestly I wouldn't know. Up till now I've never dealt with these issues.
I'm still in 'technology survey' mode ;-)
The choice to use sockets was made for efficiency reasons (timing critical
app - robotic steering/driving). The idea to use XML was mine, because it
seemed a good idea. But I can't really see the performance impact that would
be (xml parsing using xml classes vs just setting up commands in byte format
& parse). I'm already having my doubts. Plus, I am supposed to start
programming as soon as possible.
How does .net remoting fit in?
Thanks,