Introduction
I describe the collection of three programs composing group CNF.It's about a client in a client machine (cm),obtaining
informations from a server in a server machine (sm) by means of a connection point.I can name it a remote connection point.
The three programs are:
1)NFCli,an MFC7 Visual Studio .Net SDI application without ATL support;
2)SvrNear,an ATL7 Visual Studio .Net Exe Module;
3)SvrFar,an ATL7 Visual Studio .Net Exe Module.
Description
NFCli and SvrNear stay in cm,whereas SvrFar stays in sm.Sm and cm make up a LAN of 2 PC.SvrNear is registered in both
machines.SvrFar too is registered in both machines.In sm,dcomcnfg,SvrFar Properties,Security:add Everyone account for Use
custom access permissions and for Use custom launch permissions.In cm,dcomcnfg,SvrNear Properties,Security:add Everyone
account for Use custom access permissions and for Use custom launch permissions.All other properties for servers in both
machines can remain default.This application uses dcomcnfg or declarative approach to COM security:no code for security,
i.e. no programmatic approach to COM security.
The end points of communication are NFCli in cm and SvrFar in sm,whereas SvrNear,in cm,acts like a middleman between NFCli
and SvrFar.The problem,here solved,is that SvrFar's connection point needs a sink implemented in an application that allows
access to SvrFar:this application is SvrNear.
So things are arranged in this way:
NFCli knows only SvrNear's interfaces and activates SvrNear.SvrNear knows only SvrFar's interfaces and activates SvrFar.
More,SvrNear implements the sink corresponding to SvrFar's connection point.SvrFar knows no SvrNear's interfaces.
Operations all accomplished by means of interface methods:
NFCli activates SvrNear.Then NFCli passes SvrNear two strings:the first is the sm name;the second is the coclass of SvrFar.
With these two strings SvrNear in cm can activate SvrFar in sm.Then SvrNear creates the sink corresponding to SvrFar's
connection point.As bidirectional communications are now implemented,NFCli asks SvrNear to test SvrFar's connection point.
SvrNear calls a SvrFar's coclass method that fires back a notification to SvrNear sink:fire back is performed by the
connection point interface implemented by SvrFar's coclass.Notification,a string reporting SvrFar's hosting machine name,
arrives to SvrNear's sink and is copied back as output variable of the SvrNear's method before called by NFCli.So now
NFCli has obtained information from SvrFar through a connection point.Then NFCli cuts off communication releasing SvrNear's
interface pointer and in turn SvrNear cuts off communication releasing SvrFar's interface pointer.At this point SvrNear and
SvrFar are cancelled.
Installation
Put one copy of CNF in cm.Put a second copy of CNF in sm.Paths must not have spaces in their strings.From command line of cm
launch SvrNear /regserver and SvrFar /regserver.From command line of sm launch SvrNear /regserver and SvrFar /regserver.Use
dcomcnfg for SvrNear in cm and for SvrFar in sm as stated in above description.Go to cm and launch NFCli,Util,Remote Server,
write sm's name in Remote Machine Name,Connect.After a couple of seconds,by means of local/remote SCM,Get Message and
Disconnect buttons are enabled.Push Get Message and get remote machine name.Push Disconnect.
Comments
For sure it's not the only manner to communicate between client and remote server with COM/ATL,but this application concerns
about connection points.There should be better manners to use remote connection points,without need of a middleman,perhaps
by mean of programmatic approach to security.I dont' know it enough.I don't use #import directive and tlb file,but #include
_i.c and .h files:I prefere basic approach.It's practic at least with small suites of programs like this.
For hardware/software I have,it takes three seconds to make the remote connection:I thought less time.My sm is an AMD with
standard network card,my cm is an Intel with standard network card,connected to cm with cross cable.Sm has Microsoft Server
2000 and cm Microsoft Professional 2000.
Mr. Trevisan Andrea
