XML vs Sockets

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

In a project I am working on there is communication between processes over sockets. I feel like using XML for the communication (commands, status feedback, ...).

I was wondering if there is a class in C# that covers this way of working (eg XMLSocket)

Thanks
Tom.
 
Tom,

There is no class in the framework that does this inherently, but the
parts that you need to do it yourself are all there. Basically, you use the
Socket class in the System.Net namespace to establish a connection, and then
you use the XmlDocument class in the System.Xml to generate and parse the
messages. You can transfer them to the socket by reading the bytes from the
XmlDocument to a Stream (a MemoryStream would work well), and then writing
the contents of that stream back to the socket.

Now, you could use Remoting to do this. Your commands would be methods
on a class that is remoted. You won't see the XML, but it will be there if
you indicate that you want to use soap for the messaging. Remoting (using
the tcp protocol) will basically do this, but you will see it as calling
methods and getting values from those methods.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

TT (Tom Tempelaere) said:
Hi,

In a project I am working on there is communication between processes over
sockets. I feel like using XML for the communication (commands, status
feedback, ...).
 
TT (Tom Tempelaere) said:
In a project I am working on there is communication between
processes over sockets. I feel like using XML for the
communication (commands, status feedback, ...).
I was wondering if there is a class in C# that covers this way of working
(eg XMLSocket).

Actually, I did something similar quite recently. I simply encapsulated the
Socket in a NetworkStream instance and then used that NetworkStream
toghether with the XmlTextReader and XmlTextWriter classes. The code looked
something like this:

m_Socket = ...
NetworkStream ns = new NetworkStream(m_Socket, true);
m_Writer = new XmlTextWriter(ns, Encoding.UTF8);
m_Reader = new XmlTextReader(ns);

From then on, I simply used the methods available on the XmlTextReader and
XmlTextWriter classes to communicate, and it would automatically be sent
over the network. There are only two things you should be aware of.
First, make sure you always call the XmlTextWriter.Flush method after
writing something to the XML stream. If you don't, the XML will get queued
up somewhere and it will not be sent over the network. Alternatively you
could encapsulate the NetworkStream in a StreamWriter object, set the
AutoFlush property of this object to true and then pass this object to the
constructor of the XmlTextWriter.
The second thing you should be aware of is that closing the reader will
automatically close the writer (and vice versa) because underneath they're
both using the same NetworkStream.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://mentalis.org/go.php?sl
 
Will .Net Remoting not work for you?

--
William Stacey, MS MVP


TT (Tom Tempelaere) said:
Hi,

In a project I am working on there is communication between processes over
sockets. I feel like using XML for the communication (commands, status
feedback, ...).
 
William Stacey said:
Will .Net Remoting not work for you?

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,
 
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!
 
Thanks,
---
Tom Tempelaere

William Stacey said:
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,
 
Back
Top