interprocess comms in local network

[guy]

In the past I've used sockets in C++ to allow apps to communicate with each
other over a local network. Is there anything better/more advanced in .NET
or should I continue to use sockets and the .NET Socket class under C#?

The (mini) project that I'm about to start will receive stream live data
(stock market prices) and reformat that data and perform some calculations
on it before disseminating it to client applications on the local network.
Some of the machines will have just clients running and some both servers
and clients.

Thanks

[Ian Griffiths [C# MVP]]

"guy" <wi*********@hotmail.com> wrote:

In the past I've used sockets in C++ to allow apps to communicate with
each other over a local network. Is there anything better/more advanced
in .NET or should I continue to use sockets and the .NET Socket class
under C#?

You have various options. If you want something RPC-like (Remote Procedure
Call) then you can use .NET Remoting. This makes it fairly straightforward
for one process to invoke methods on another process.

There are some shortcomings. First, while remoting is good for connecting
two different parts of one application, it is not quite so good for
connecting two independently written applications. It doesn't have any
built-in support for dealing with a situation where each end of the link
evolves independently. This is largely because .NET remoting relies on both
ends sharing a certain amount of type information. (You need to have type
definitions available at both client and server.) It is possible to deal
with this, but remoting doesn't go out of its way to make it easy.

However, if you're always going to release updates to both ends of the
connection simultaneously, this isn't a big deal.

Also, remoting currently has no integrated security support. This changes
with Whidbey - I believe a secure channel will ship with that. Meanwhile,
if you want to secure your remote channel, there's an unsupported way of
doing this on .NET v1.x today:

http://msdn.microsoft.com/library/de...asp?frame=true
http://msdn.microsoft.com/library/de...asp?frame=true
Web Services may be another option. (Indeed, there seems to be a common
idea that these have already deprecated remoting, but that's not accurate.
Each technology has its uses.) Using the web service infrastructure to
receive messages requires you to use ASP.NET. If you don't mind hosting the
app in a web server, that's easy. If you want it to be standalone, that's
possible, but a lot more effort. (You can host ASP.NET in any process you
like.)
But if neither of these looks like a good match for the kind of data you are
sending, or the manner in which you want to send and process messages (the
request/response nature of both of these implementations might not suit your
application) then simple sockets may well be a better bet.
--
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/

[guy]

Hi Ian,

Many thanks for your speedy response.

Since writing I've been thinking that at some point I may want this
application to break out of the local area network and be available on
remote machines across the internet.

I'm thinking that ASP.NET might give me this. Is this right?

On a small local area network do I need to set something special up to use
ASP.NET? You mentioned Web Services. Is this a service that is available on
XP that just needs to be started?

Web Services may be another option. (Indeed, there seems to be a common
idea that these have already deprecated remoting, but that's not accurate.
Each technology has its uses.) Using the web service infrastructure to
receive messages requires you to use ASP.NET. If you don't mind hosting
the app in a web server, that's easy. If you want it to be standalone,
that's possible, but a lot more effort. (You can host ASP.NET in any
process you like.)

Many thanks for your help.
guy

[Ian Griffiths [C# MVP]]

"guy" <wi*********@hotmail.com> wrote:

Since writing I've been thinking that at some point I may want this
application to break out of the local area network and be available on
remote machines across the internet.

I'm thinking that ASP.NET might give me this. Is this right?
Yes, although in principal Remoting could too. You can configure a remoting
channel to listen on any port you like. And there's an HTTP channel
available too if that's the only thing that will tunnel through your
firewall.

But the web services route would probably be a better solution here. The
reason I say that is that if you are deploying applications out on the
internet, you probably want to use a technology that is as robust as
possible in the face of changing requirements - you're probably not going to
have the luxury of being able to update all the clients simultaneously when
you update the server.

Not that you get this kind of versioning-robustness for free using web
services, it's just easier to achieve.

On a small local area network do I need to set something special up to use
ASP.NET? You mentioned Web Services. Is this a service that is available
on XP that just needs to be started?

ASP.NET provides support for implementing a web service. (Specifically, the
server half of it.) The ASP.NET framework is installed as standard with the
..NET Framework, so if you've got the .NET Framework, you've got ASP.NET.

However, you need a host process in which to run ASP.NET in order to use it.
The usual way of doing this is to use the standard IIS-based hosting. If
IIS was installed when you installed the .NET Framework, it will have set up
the standard IIS-based hosting of ASP.NET. If it wasn't install IIS, and
then run this command:

aspnet_regiis -i

You'll find that command in C:\windows\microsoft.net\framework\v1.1.4322.
This configures IIS to allow ASP.NET applications to be hosted. (This adds
an ISAPI extension that directs requests with certain extensions through to
an ASP.NET worker process. This process is called aspnet_wp.exe and is
started up on demand when you first hit an ASP.NET resource via IIS. Unless
you're on Windows Server 2003, in which case it'll call the process
wpw3.exe.)

Once you've made sure ASP.NET is registered with IIS, you can then create a
web service. For example, put a file in \inetpub\wwwroot and give it a
".asmx" extension, e.g. "MyService.asmx". Make it something like this:

<%@ WebService language="c#" class="MyService" %>

using System.Web.Services;

public class MyService
{
[WebMethod]
public int Add(int x, int y)
{
return x + y;
}
}
You have now exposed MyService.Add as a web service. Try looking at the
http://localhost/MyService.asmx file (or whatever you chose to call it) in
your web browser, and it will generate some documentation telling you how to
use the web service.

You don't have to host via IIS though. The ASP.NET framework is happy to be
hosted in any process. For example, this:

http://www.iunknown.com/000099.html

shows how to host ASP.NET from inside of a Windows Forms application.
If you're using VS.NET, you can get it to generate you a wrapper class to
consume a web service from the client side.
--
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/

[guy]

Thanks for all the info Ian. Let me absorb this and do some further
investigating using the links and ideas that you've given me. Your time and
effort in the reply is much appreciated.

I'll keep you posted on my progress and discoveries...

[guy]

Hi Ian,

Many thanks for your replies and help a few weeks ago. I got side tracked on
another project but now I'm back on this one.

Has anyone written an article comparing the different methods of
interprocess communication across the internet.

My objective is to write a client/server application.

They won't be very complicated but will do this:

Server
Connects to a live data feed (via Excel) and retrieves data.
Does some calculations on the data.
Distributes data to clients on remote machines on internet.
Server needs to be an application with buttons and menus as it will need to
manipulated while it's running.

Client
Displays the data it receives.
Also an application with menus etc.

I also need to set up permissioning such that only clients that I've
authorized can connect to the server.

Is there a template of this sort of application that I can use as a starting
point.

Many thanks
Guy

"Ian Griffiths [C# MVP]" <ia*************@nospam.nospam> wrote in message
news:OV**************@TK2MSFTNGP14.phx.gbl...

"guy" <wi*********@hotmail.com> wrote:

Since writing I've been thinking that at some point I may want this
application to break out of the local area network and be available on
remote machines across the internet.

I'm thinking that ASP.NET might give me this. Is this right?

Yes, although in principal Remoting could too. You can configure a
remoting channel to listen on any port you like. And there's an HTTP
channel available too if that's the only thing that will tunnel through
your firewall.

But the web services route would probably be a better solution here. The
reason I say that is that if you are deploying applications out on the
internet, you probably want to use a technology that is as robust as
possible in the face of changing requirements - you're probably not going
to have the luxury of being able to update all the clients simultaneously
when you update the server.

Not that you get this kind of versioning-robustness for free using web
services, it's just easier to achieve.

On a small local area network do I need to set something special up to
use ASP.NET? You mentioned Web Services. Is this a service that is
available on XP that just needs to be started?

ASP.NET provides support for implementing a web service. (Specifically,
the server half of it.) The ASP.NET framework is installed as standard
with the .NET Framework, so if you've got the .NET Framework, you've got
ASP.NET.

However, you need a host process in which to run ASP.NET in order to use
it. The usual way of doing this is to use the standard IIS-based hosting.
If IIS was installed when you installed the .NET Framework, it will have
set up the standard IIS-based hosting of ASP.NET. If it wasn't install
IIS, and then run this command:

aspnet_regiis -i

You'll find that command in C:\windows\microsoft.net\framework\v1.1.4322.
This configures IIS to allow ASP.NET applications to be hosted. (This
adds an ISAPI extension that directs requests with certain extensions
through to an ASP.NET worker process. This process is called
aspnet_wp.exe and is started up on demand when you first hit an ASP.NET
resource via IIS. Unless you're on Windows Server 2003, in which case
it'll call the process wpw3.exe.)

Once you've made sure ASP.NET is registered with IIS, you can then create
a web service. For example, put a file in \inetpub\wwwroot and give it a
".asmx" extension, e.g. "MyService.asmx". Make it something like this:

<%@ WebService language="c#" class="MyService" %>

using System.Web.Services;

public class MyService
{
[WebMethod]
public int Add(int x, int y)
{
return x + y;
}
}
You have now exposed MyService.Add as a web service. Try looking at the
http://localhost/MyService.asmx file (or whatever you chose to call it) in
your web browser, and it will generate some documentation telling you how
to use the web service.

You don't have to host via IIS though. The ASP.NET framework is happy to
be hosted in any process. For example, this:

http://www.iunknown.com/000099.html

shows how to host ASP.NET from inside of a Windows Forms application.
If you're using VS.NET, you can get it to generate you a wrapper class to
consume a web service from the client side.
--
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/