MSDN Home > MSDN Library > Win32 and COM Development > Component Development > DCOM > |
Marc Levy April 23, 1999 ContentsIntroduction IntroductionComponent Object Model (COM) Internet Services (CIS) introduces support for a new Distributed COM (DCOM) transport protocol known as Tunneling Transmission Control Protocol (TCP) that allows DCOM to operate over TCP port 80. This allows a client and a server to communicate in the presence of most proxy servers and firewalls, thereby enabling a new class of COM-based Internet scenarios. In addition to the new DCOM protocol, CIS also provides a new type of simple monikerthe OBJREF monikerthat facilitates the use of COM in Internet scenarios. The OBJREF moniker represents a reference to a running object and has a display name that can, for example, be embedded in an HTML page and bound by an ActiveX® control or client applet. This article explains what the COM Internet Services are, how they work, and how to configure computers running Microsoft® Windows® to use the services. The article assumes the reader has a basic understanding of distributed COM and the DCOM configuration tool. A New DCOM Transport ProtocolIn many Internet situations, the network connectivity between a client and a server is subject to a number of restrictions. For example:
In practice, the net effect of such restrictions is that a client and a server will probably have a very narrow set of protocol and port combinations available to carry out a conversation. Because DCOM dynamically selects network ports in a range (1024 65535) on which Internet-to-intranet network traffic is typically not allowed, it is not possible to reliably use the existing DCOM transport protocols over the Internet (although they are perfectly suitable for intranets). Moreover, firewalls are often set up to restrict access to port 135, upon which DCOM depends for a variety of services (see Endnote 1). The Tunneling TCP protocol introduces a special handshake at the beginning of each DCOM connection that allows it to pass through most firewalls and proxies. After this handshake, the wire protocol is simply DCOM over TCP. Aside from the caveats listed later in this article, this means:
Limitations of the Tunneling TCP ProtocolThe Tunneling TCP protocol is subject to the following limitations:
Note that because of these limitations, in practice, CIS does not support callbacks. This means, for example, that your applications cannot perform notifications using the connection point or advise sink mechanisms. However, if the CIS client can function as a CIS server and is configured as discussed later in this article, nothing prevents the client from receiving DCOM callsincluding callbacks. Protocol OverviewThe Tunneling TCP protocol is illustrated in Figure 1. Figure 1. The Tunneling TCP Protocol
Configuring the Tunneling TCP ProtocolThe Tunneling TCP protocol is supported on the operating systems listed in Table 1. This section describes how to configure the protocol on supported operating systems. Installation instructions are provided in the operating system or service pack release notes, as appropriate. Table 1. Operating system support for Tunneling TCP
Client ConfigurationWindows 95 and Windows 98CIS requires that DCOM95 1.2 or a later version be installed on your Windows 95 machine. DCOM95 1.2 is available for download from the Microsoft COM Home Page, www.microsoft.com/com/default.asp. On Windows 98, you must have DCOM98 1.3 or later installed. DCOM98 1.3 will ship with Windows 98 OSR1 and can also be downloaded from the Microsoft COM Home Page. To enable CIS client support, run the CISCNFG utility as follows: CISCNFG tcp_http CISCNFG configures the protocols that DCOM uses and can be used with the following arguments:
After running CISCNFG, you must reboot your system. Windows NT 4.0 SP4 and Windows 2000CIS support is included with Windows NT 4.0 Service Pack 4 and Windows 2000. To enable CIS, you need to add the Tunneling TCP protocol to the DCOM protocol list. You can modify the protocol list by running DCOMCNFG.
Note If multiple protocols are configured, DCOM attempts to use them in the order in which they appear in the DCOM protocol list. HTTP proxy configurationIf your client is located behind a proxy server, you need to ensure that your client machine is correctly configured to use the proxy server to access the web. To configure your client to use the proxy server, open Internet in the Control Panel. This can also be set via a registry key as described in the section "Registry Keys Affecting CIS". Note that this configuration is shared with the RPC run-time environment by other applications that use HTTP, most notably Microsoft Internet Explorer. Server ConfigurationConfiguring the RPC Proxy on Windows NT Server 4.0CIS requires that Service Pack 4 be installed on your Windows NT Server 4.0 computer. CIS also requires that Internet Information Server 4.0 (including the Internet Service Manager) be running. IIS 4.0 is part of the Windows NT 4.0 Option Pack. Note CIS should not be installed on a machine running Microsoft Proxy Server.
Configuring the RPC Proxy on Windows 2000 ServerOn the Windows 2000 Server, CIS requires that the Internet Information Services (including the Internet Services Manager) be running. On Windows 2000 Server, CIS has its own optional network setup (it is not installed by default). It can be installed just like other optional network components:
You can add CIS during the initial Windows 2000 Server install, or add it later to an existing system. On an upgrade from a Windows NT 4.0 (SP4) Server that already has CIS installed to Windows 2000, you will need to reinstall CIS as described above. Enabling CISTo enable CIS on the server, you need to add the Tunneling TCP protocol to the DCOM protocol list. You do this by running DCOMCNFG.
In addition, it is possible to control whether or not CIS is enabled by changing the value of a DCOM property. This setting, which defaults to "disabled," can act as a coarse-grained security control to disable potential Internet access to DCOM. Note, however, that even when CIS is enabled, the usual DCOM security checks remain in effect. Run DCOMCNFG to set this property:
Proxy Server ConfigurationIf the client is configured to access the Internet through a proxy, the proxy server must be configured to enable the HTTP CONNECT method for the port to which the client connects (port 80 by default). This port configuration is sometime referred to as "enabling SSL tunneling." Consult the documentation for your proxy server for details on how to configure a port for the HTTP CONNECT method. Configuring Microsoft Proxy ServerIf you are using Microsoft Proxy Server, enabling HTTP CONNECT is achieved by manipulating a registry key (for example, using regedt32.exe) to indicate what ports should allow HTTP CONNECT. In the default configuration, two ports are enabled: 443 (https) and 563 (snews). The registry key of interest is: HKEY_LOCAL_MACHINE\system\CurrentControlSet\services\w3proxy\parameters\SSLPortListMembers The key value consists of a list of pairs of ports. For the default proxy configuration (handling HTTP traffic on port 80), add the pair "80 80" to the existing registry values. After making this modification, you will need to stop and restart the Microsoft Proxy Server for the new settings to take effect. Firewall ConfigurationThe only configuration requirement placed by CIS on the firewall is that it allows TCP/IP traffic through port 80 unimpeded. Because port 80 is usually open to HTTP traffic, this is the standard scenario. In some rare cases, however, a firewall performs so-called application-level filtering on incoming traffic that may result in CIS traffic being rejected. Configuration Tips and Known IssuesIncorrect proxy server settings on the CIS clientThe proxy server setting on the client should not contain any leading forward slash ("/"). For example, the reference
in the registry. CIS server side should not be installed on a machine hosting Microsoft Proxy ServerThe RPC proxy, RpcProxy.dll, does not function properly when installed on a machine hosting Microsoft Proxy Server. Issue with a multihomed CIS serverA client of a multihomed CIS server activating an object using one of the server IP addresses can cause failure. To work around this limitation, the client should use the server name (for example, the DNS name). MTS use of callbacksWhen a client and a server share a transaction in a Microsoft Transaction Server (MTS) scenario, the MTS infrastructure makes a callback to the client. This scenario is not supported with CIS unless the client machine is configured as a CIS server. Note, however, that this limitation does not hinder the most common transaction scenario for a base client, the case of a client not in a transaction calling a component that requires one. Issue with HTTP caching devicesHTTP caching devices (for example, Cisco LocalDirector) may need to be tweaked or disabled. Registry Keys Affecting CIS
OBJREF MonikerTo allow clients to establish connections to an object already running on a remote server, CIS provides a new type of simple moniker known as the OBJREF moniker. This moniker provides a simple mechanism for embedding references to remote objects in an HTML page. OBJREF monikers are monikers that represent references to local or remote objects running on a distributed system. The OBJREF moniker represents a particular running instance on a particular server. If the object instance terminates, then the OBJREF moniker is invalid. If a moniker is created from a proxy to a remote object and bound on a different machine, the moniker will bind to the original object in keeping with the DCOM short-cut semantics. If the object cannot be located during an attempt to bind, no new objects will be launched. In many ways, the semantics of the OBJREF moniker are similar to that of a pointer moniker and essentially represent a remote pointer to a running object. However the display name of an OBJREF moniker may be embedded in an HTML page and bound by a client applet or ActiveX control. Note For additional details, see the OBJREF moniker reference documentation in the Platform SDK. When To UseAn active server page (or some other means of generating dynamic HTML content) may place the display name of an OBJREF moniker in a parameter to an applet or ActiveX control. The applet or control can then use the moniker to connect to the running object instance on the remote server. To use OBJREF monikers, the server code generating the moniker must use the CreateObjrefMoniker function to create the monikers, passing an interface to the object that the moniker will bind. EndnotesEndnote 1. For a discussion of firewall issues, with DCOM over TCP applicable to some firewall scenarios, the reader is referred to Michael Nelson's article "Using Distributed COM with Firewalls". Endnote 2. This may include the initial additional step of contacting the DCOM Service Control Manager on <server host> to resolve the DCOM server endpoint. Endnote 3. This may include the initial additional step of contacting the DCOM Service Control Manager on <server host> to resolve the DCOM server endpoint. |