As Mohammoss pointed out, if you stay inside a .NET environment (on
both sides of your communications) it is much easier and feature-rich
to use a .NET communication technology like .NET Remoting (which is not
the only possible solution, I'm just thinking about WS ...).
BTW, Remoting is a customizable infrastructure where you can choose the
transport protocol you wish to use (HTTP and TCP are provided but you
can implement your own channels). Sockets may be used under the hood
(they almost always are, since the TCP channel relies on socket
communication, as well as the HTTP channel does, although this is often
hidden by the server host).
You can surely use "raw" sockets.
What you need is, though, to define a protocol on which both the client
and the server do agree.
Defining a protocol is just about defining what raw data streams (the
byte[] you send) represent from a logical perspective.
So the client should translate its high-level data into a byte array
(serialization) which is sent over the wire; your server will use the
same translation mechanism to deserialize the input stream into a copy
of the original high-level data.
You might, for example, leverage the .NET serialization features in
order to serialize an object and later deserialize it.
It's impossible to give you a complete overview neither about .NET
serialization, or about .NET Remoting or inter-process communication in
general.
I would suggest you to take a look at the MSDN web site
(msdn.microsoft.com), which has lots of valuable contents and samples.
HTH
Claudio Brotto
