Sockets

  • Thread starter Thread starter Guest
  • Start date Start date
Welcome to the world of distributed programming - theres a whole new world of things you have to think abouit. The first one here is what do you want to happen when you pass this object when the recipient calls it? Do you want the call to come back to the sender or do you want the call to stay on teh remote machine?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

How do I send an object from one computer to another?
 
Well if you just want the public fields of an object (say a class is an
abstract db record) then you can just use XmlSerializer to serialize the
class to an xml string. Now that you have the string you can easily get the
bytes using Encoding.UTF8.GetBytes(), etc. Now you have the bytes, you can
send in a UDP datagram or send via TCP stream. If using TCP, you probably
want to append a len ushort to the byte[]. Then the receive side will read
the first two bytes, convert to a ushort and then read that many bytes to
know it got all the bytes. Then close or wait for more data. The receiver
will also convert the bytes back to a string, and deserialize string to an
object. Both sides need to know what "object" looks like, so you can
include the same class code at both sides. One way to do that is create a
shared dll. This dll may be nothing more then all the "shared" objects or
data tranfer objects (DTOs). In a sense, I guess the class defines the
shared schema or contract of what both sides expect to send and receive in
terms of object data. Like Richard said, this is a big topic with various
ways to go and can get complex. Today, you have many techs to choose from
to do this. You have WSE, web services, Remoting, and native sockets using
your own "wire" protocol (and others). Using xml over sockets is probably a
good way to start as you get a handle on it from ground up, and get a feel
for why and how the others work the way they do. The other techs are
variations on their own xml over socket technologies. Remoting does not use
xml, but you could think of it as its own propriatary binary markup
language. All of them output byte[] of some kind that must be sent over a
udp or tcp socket. Indigo will be MSs next version of xml over sockets that
will combine ~all the others into one api set.
 
The class I want to send is already on both computers, however, I just want
to know how to Asyncronously send an instance of the class back and forth
from computer to computer.

William Stacey said:
Well if you just want the public fields of an object (say a class is an
abstract db record) then you can just use XmlSerializer to serialize the
class to an xml string. Now that you have the string you can easily get the
bytes using Encoding.UTF8.GetBytes(), etc. Now you have the bytes, you can
send in a UDP datagram or send via TCP stream. If using TCP, you probably
want to append a len ushort to the byte[]. Then the receive side will read
the first two bytes, convert to a ushort and then read that many bytes to
know it got all the bytes. Then close or wait for more data. The receiver
will also convert the bytes back to a string, and deserialize string to an
object. Both sides need to know what "object" looks like, so you can
include the same class code at both sides. One way to do that is create a
shared dll. This dll may be nothing more then all the "shared" objects or
data tranfer objects (DTOs). In a sense, I guess the class defines the
shared schema or contract of what both sides expect to send and receive in
terms of object data. Like Richard said, this is a big topic with various
ways to go and can get complex. Today, you have many techs to choose from
to do this. You have WSE, web services, Remoting, and native sockets using
your own "wire" protocol (and others). Using xml over sockets is probably a
good way to start as you get a handle on it from ground up, and get a feel
for why and how the others work the way they do. The other techs are
variations on their own xml over socket technologies. Remoting does not use
xml, but you could think of it as its own propriatary binary markup
language. All of them output byte[] of some kind that must be sent over a
udp or tcp socket. Indigo will be MSs next version of xml over sockets that
will combine ~all the others into one api set.
Click to expand...
 
I just told you one way. You can use Remoting or sockets. As you talked
about sockets, I told you how to use XmlSerializer to do it. I assume you
know how to send bytes, so all you need to convert your class instance into
bytes using xmlserializer and an Encoding to convert the string to bytes.
Check the XmlSerializer doco. It is really helpful. If you have specific
questions, please reply.

--
William Stacey, MVP
http://mvp.support.microsoft.com

Bill English said:
The class I want to send is already on both computers, however, I just want
to know how to Asyncronously send an instance of the class back and forth
from computer to computer.

William Stacey said:
Well if you just want the public fields of an object (say a class is an
abstract db record) then you can just use XmlSerializer to serialize the
class to an xml string. Now that you have the string you can easily get the
bytes using Encoding.UTF8.GetBytes(), etc. Now you have the bytes, you can
send in a UDP datagram or send via TCP stream. If using TCP, you probably
want to append a len ushort to the byte[]. Then the receive side will read
the first two bytes, convert to a ushort and then read that many bytes to
know it got all the bytes. Then close or wait for more data. The receiver
will also convert the bytes back to a string, and deserialize string to an
object. Both sides need to know what "object" looks like, so you can
include the same class code at both sides. One way to do that is create a
shared dll. This dll may be nothing more then all the "shared" objects or
data tranfer objects (DTOs). In a sense, I guess the class defines the
shared schema or contract of what both sides expect to send and receive in
terms of object data. Like Richard said, this is a big topic with various
ways to go and can get complex. Today, you have many techs to choose from
to do this. You have WSE, web services, Remoting, and native sockets using
your own "wire" protocol (and others). Using xml over sockets is probably a
good way to start as you get a handle on it from ground up, and get a feel
for why and how the others work the way they do. The other techs are
variations on their own xml over socket technologies. Remoting does not use
xml, but you could think of it as its own propriatary binary markup
language. All of them output byte[] of some kind that must be sent over a
udp or tcp socket. Indigo will be MSs next version of xml over sockets that
will combine ~all the others into one api set.

--
William Stacey, MVP
http://mvp.support.microsoft.com

Bill English said:
How do I send an object from one computer to another?
Click to expand...
Click to expand...
Click to expand...
 
..Net remoting is a good place to start. I would start your research there.
If you go this way, you may also want to try copying your object from one
application to another first. Many of the same skills are required and you
wont have to hassle with two machines at first.

More information:

I always find it helpful to think of networking in terms of the layering of
increasing complex protocols. You need to make sure that your communication
is established properly at the lower levels before moving to the higher
levels. The first thing you need is a physical connection between the two
machines (like a network cable). Then you need a way to pass generic
information between machines like tcp/ip. Then you will want to layer more
complex protocols on top of this to accomplish your task. The complexity of
each layer has resource and performance costs that need to be weighed
against available resources and performance requirements. Lower level
protocols will most likely be faster, less resource intensive, and more
versatile, but require more effort to implement and are harder to read when
revisited.

That being said it is important to understand your problem space. You want
to send an object from one computer to another. However, you are really not
sending an object from one computer to another. You are making a copy of an
object from one computer on another computer. If you have the class
definition on both machines then you can create an object instance on both
machines. Then you need to transmit the state of the source object from one
machine to the other and update the state of the destination object with
that state information. You will need to take your source object and
serialize its state into a data stream. You are basically packaging it in a
compact form for transmission across the wire. When it goes across the wire
you will then want to reassemble it into a usable form, i.e. your object.
You would have to perform a similar operation even communicating from one
program to another. Obviously you wouldn't be sending object state across
machine boundaries, but you would be sending it across process boundaries.

There are technologies that perform this type of action in one form or
another depending on the needs of the application and the environment in
which your objects will communicate. .Net remoting is one of those
technologies. It provides you the ability to work on a copy of an object or
to appear to act on one object from different machines by updating the
original when the copy is acted on. There are a lot of problems inherent in
working on remote objects as if they were local. It is appropriate in
certain situations especially if you are in control of all aspects of the
system in which the objects are contained and there are not a ton of users
accessing the object. However, if the system is more spread out and the
environment not so controlled you may want to work with copies or consider
other alternatives. An evolving school of thought is Service Orientation or
SOA (Service Oriented Applications)
 
Back
Top