bi-directional Remoting or Sockets ?

[Rogier]

Hello,

I want to make a client/server app, for a game. Where I can send object
to and from the server. With this I mean the client can send an object
to the server but the server can also send an object to the client (not
in a respond). So I need a sort of bi directional solution. I've
searched the net for some solutions. And remoting allows me to send
objects but I can't find wether it is bi-directional. Does any one know
a good solution for this problem. Or do I have to implement the client
also as a server.

 

[Kerem Gümrükcü]

Hello,

I want to make a client/server app, for a game. Where I can send object to
and from the server. With this I mean the client can send an object to
the server but the server can also send an object to the client (not in a
respond). So I need a sort of bi directional solution. I've searched the
net for some solutions. And remoting allows me to send objects but I can't
find wether it is bi-directional. Does any one know a good solution for
this problem. Or do I have to implement the client also as a server.

Hi Rogier,

if you are working on a game then you really should
do your task with sockets, since sockets give you some
kind of connection-freedom and client/server independence.
You can build them on TCP/IP v4/6 and every System
on the other end, no matter what Operating System can
talk with your client and server. The only prerequisit would
be a TCP/IP enabled system and this is the default today.
If you use .NET Remoting, then you will be "bound" to
a .NET Remotable system and be sure that there will be
not everywhere a .NET System available. If you programm
on a game this "connection-indipendence" will even give you
the abillity to develop your clients/and server in any TCP/IP
socket handling enabled programming language: Java, C/C++
or whatever can use TCP/IP Sockets.

Consider the Situation when someone wnats to connect to
your system from a Macintosh or some sort of Unix/Linux.
Maybe there will be no .NET Framework on the other End
of the Connection.

I can and will heavilly recommend the socket solution,
though .NET Remoting is a very good thing!

Beste Grüsse / Best regards / Votre bien devoue

Kerem Gümrükcü
(e-mail address removed)
Pro-IT Education http://www.pro-it-education.de/
Professional IT-Training and Consulting

 

[Nicholas Paldino [.NET/C# MVP]]

Rogier,

If Kerem's concerns are not important to your app (you will always be
using .NET on both sides, for example), then what you want to do is have
your service take an instance of an object that derives from
MarshalByRefObject. Then, the client will pass an instance of this derived
object to the server. The server can then hold a reference to the object,
and make calls on it anytime it wants.

When an object is passed across the app domain boundary through
remoting, and it derives from MarshalByRefObject, when calls are made to it
on the server side, the calls are marshaled back to the client, which is
what I believe you want.