DCOM - Ingeniørhøjskolen i Århus

dingdongboomNetworking and Communications

Oct 27, 2013 (4 years and 16 days ago)

107 views

OOMI

A short introduction to

Microsoft's COM

From COM to DCOM

Ingeniørhøjskolen i Århus

Slide
2

af 24

Agenda


From COM to DCOM


DCOM architecture


DCOM How to program


Ingeniørhøjskolen i Århus

Slide
3

af 24

From COM to DCOM


“DCOM is just COM with a longer wire” ;
-
)


It’s possible to configure even an in
-
proc COM
-
server
DLL to be accessed from a remote PC


But there are differences:


New kind of errors


Slower response times


Security becomes a very important subject


No GUI
-

server objects can’t access GUI on Client


Marshalling necessary


done in proxy
-
stub
-
DLL

Ingeniørhøjskolen i Århus

Slide
4

af 24

Client

Component

In the same process

Fast, direct function calls

Client

Component

COM

Client Process

Server Process

On the same machine

Fast, secure IPC

Across machines

Secure, reliable and
flexible DCE
-
RPC

based
DCOM

protocol

COM

DCE

RPC

Client

Server Machine

Client Machine

COM

Component

Accessing COM Services

Ingeniørhøjskolen i Århus

Slide
5

af 24

DCOM: Multiple Network Transports

TCP, UDP

IPX, SPX

HTTP

Server Machine

Client Machine

C

O

M

Queued

Clients

C

O

M

COM

Object

Ingeniørhøjskolen i Århus

Slide
6

af 24

DCOM: Flexible Security

TCP, UDP

IPX, SPX

HTTP

C

O

M

Queued

NT4 Security

SSL/

Certificates

Kerberos

IPSEC

C

O

M

COM

Object

Clients

Client Machine

Server Machine

Ingeniørhøjskolen i Århus

Slide
7

af 24

COM

Client

Linux 2.0 (Intel)


BETA

COM

HP/UX

COM

Digital Open VMS

COM

Siemens Nixdorf SINIX

COM

SCO UnixWare

COM

Digital Unix 4.0 (Alpha)

RC

COM

IBM MVS 5.2.2 (OS390)

COM

IBM OS/400

COM

IBM AIX

COM

DCOM

Sun Solaris (Sparc) 2.5


RC

COM

Q3’97

Q3’97

Q1’98

H1’98

H1’98

H1’98

Q4’97

H1’98

H1’98

Q4’97

COM: Ubiquitous

Ingeniørhøjskolen i Århus

Slide
8

af 24

Threading model: STA

Alternative: Free Threading model


hard to master

Ingeniørhøjskolen i Århus

Slide
9

af 24

DCOM Access Transparency


All COM components communicate in the same way


on the same machine


In
-
process or


Out
-
of
-
process


across a Local Area Network


across a Wide Area Network


across the Internet


Same tools, knowledge, code

Ingeniørhøjskolen i Århus

Slide
10

af 24

DCOM Wire Protocol


Wire Protocol


Based on DCE RPC Specification


Interoperable with OSF DCE RPC implementations


MS call it “ORPC”


Efficient and Scalable


Documented in Internet
-
Draft


(ftp://ietf.org/internet
-
drafts/draft
-
brown
-
dcom
-
v1
-
spec
-
01.txt)

Ingeniørhøjskolen i Århus

Slide
11

af 24

Server

Client

Efficient and Scalable


Multiplexing
-

Single Port per
-
protocol, per server process, regardless
of # of objects


Scalable
-

Connection
-
Less Protocols like UDP Preferred


Established Connection
-
Oriented (TCP) Sessions Reused by same
client

Client

Ingeniørhøjskolen i Århus

Slide
12

af 24

Server Machine

Client Machine

Server

Client #1

Client #2

Keep
-
Alive
Traffic

for all
connections

Efficient and Scalable


Low Bandwidth


Header is 28 bytes over DCE
-
RPC


Keep
-
Alive Messages bundled for all connections between
Machines

Ingeniørhøjskolen i Århus

Slide
13

af 24

Scorecard

Ingeniørhøjskolen i Århus

Slide
14

af 24

DCOM How to activate a server


Like all COM communication, everything starts when the
client requests an interface from a server.


In DCOM, the client calls CoCreateInstanceEx(), passing
in a description of the server computer and requesting a
class identifier (CLSID) and Interface.


This request is handled by the Service Control Manager
(SCM), which is a part of Windows. The SCM is
responsible for the creation and activation of the COM
object on the server computer.


In the case of DCOM, the SCM will attempt to launch the
server on the remote computer.


Ingeniørhøjskolen i Århus

Slide
15

af 24

DCOM System Relationships


Once the remote COM server has been created, all calls will be
marshaled through the proxy and stub objects.


The proxy and stub communicate using RPCs (Remote Procedure
Calls), which handle all the network interaction.


On the server side, the stub object takes care of marshaling.


On the client, the proxy does the work.


The standard RPC protocol is UDP (User Datagram Protocol).


UDP is a connectionless protocol, which seems like a bad fit for a
connection
-
oriented system like DCOM. This isn't a problem however;
DCOM automatically takes care of connections.

Ingeniørhøjskolen i Århus

Slide
16

af 24

The Server Doesn't Change (much)


Any COM server that runs as a program (EXE) will work
across a network.


In general, you don't have to make any changes to a
server to get it to work for DCOM.


You may, however, want to add some security to your
server, which will involve some effort.


If you're using an in
-
process server (DLL), you will need to
make some changes.


An in
-
process server is a DLL, which can't load across a network.


A DLL loads into the client program's address space, which will not
work for remote connections.


There is a work
-
around called a
surrogate
, which wraps the DLL in
an executable program


However, it is usually more appropriate to change the server DLL
over to an EXE.


Ingeniørhøjskolen i Århus

Slide
17

af 24

Adding DCOM to the Simple Client


The first thing you do in any COM program is call
CoInitialize.


Simple clients use the default threading model,
which is
apartment threading STA
.


// initialize COM

hr = CoInitialize(0);

Ingeniørhøjskolen i Århus

Slide
18

af 24

Specifying the Server with COSERVERINFO


When making a remote DCOM connection you
must specify the server computer.


The name of the computer can be a standard
UNC computer name or a TCP/IP address.

char name[32];



// remote server info

COSERVERINFO cs;

// Init structures to zero

memset(&cs, 0, sizeof(cs));

// Allocate the server name in the COSERVERINFO struct

// use _bstr_t copy constructor

cs.pwszName = _bstr_t(name);

Ingeniørhøjskolen i Århus

Slide
19

af 24

Specifying the Interface with MULTI_QI


Normally, we get an interface pointer by calling CoCreateInstance.


For DCOM we need to use the extend version, CoCreateInstanceEx.


This extended function works perfectly well for local COM servers as
well.


CoCreateInstanceEx has several important differences.


it lets you specify the server name


it allows you to get more than one interface in a single call.

// structure for CoCreateInstanceEx

MULTI_QI qi[2];

// Array of structures

// set to zero

memset(qi, 0, sizeof(qi));

// Fill the qi with a valid


// interface

qi[0].pIID = &IID_IGetInfo;

qi[1].pIID = IID_ISomeOtherInterface;

// get the interface pointer

hr = CoCreateInstanceEx(


CLSID_GetInfo,
// clsid


NULL,
// outer unknown


CLSCTX_SERVER,
// server context


&cs,
// server info


2,
// size of qi


qi );
// MULTI_QI array

Ingeniørhøjskolen i Århus

Slide
20

af 24

The MULTI_QI structure


The MULTI_QI structure holds three pieces of
information:


a pointer to the IID


the returned interface pointer


an HRESULT.


typedef struct tagMULTI_QI

{


// pass this one in


const IID *pIID;


// get these out (must set NULL before calling)


IUnknown *pItf;


HRESULT hr;

} MULTI_QI;

Ingeniørhøjskolen i Århus

Slide
21

af 24

The rest is just normal COM client code


There's nothing special about DCOM clients once
you've connected to the server.


There is one big difference though: errors.


// pointer to interface

IGetInfo *pI;

if (SUCCEEDED(hr))

{


// Basic style string


BSTR bsName;


// Extract the interface from the MULTI_QI structure


pI = (IGetInfo*)qi[0].pItf;


// Call a method on the remote server


hr = pI
-
>GetComputerName( &bsName );


pI
-
>Release();


...

Ingeniørhøjskolen i Århus

Slide
22

af 24

Registration on the Server


If you're working on a single machine, registration for
DCOM is identical to standard COM.


The server program will typically register itself when you
run it with the
-
REGSERVER switch.


ATL
-
generated servers will have registration code built into
them.


When the EXE is run with the
-
REGSERVER switch, it
registers itself in the system registry and exits.


If you use custom interfaces then the proxy/stub DLL is
required on both the server and the client machine.

C:
\
>
remoteServer


regserver

C:
\
> REGSVR32
remoteserverps
.dll

Ingeniørhøjskolen i Århus

Slide
23

af 24

Registration on the Client


If you use custom interfaces then the proxy/stub DLL is
required on the client machine.


The proxy/stub is the component that will send all
information between the client and server over the
network.


To use a proxy/stub DLL, you need to register it on the
client so DCOM can automatically activate it.


If you're using an IDispatch (or dual) based automation
client, you won't have a proxy/stub DLL.


In this case, you'll use a type library to register.

C:
\
> REGSVR32
remoteserverps
.dll

Ingeniørhøjskolen i Århus

Slide
24

af 24

Security is a major issue


But we will ignore it


for now.


You can manipulate security settings for both the client
and sever in your program.


This is done with the CoInitializeSecurity API call.


You can use this call to either:


Add security


Turn off security


You call this method immediately after calling CoInitialize.

// turn off security
-

overrides defaults

hr = CoInitializeSecurity(NULL,
-
1, NULL, NULL,


RPC_C_AUTHN_LEVEL_NONE,


RPC_C_IMP_LEVEL_IMPERSONATE,


NULL,


EOAC_NONE,


NULL);