With reference to the frequency of the calls, TCP connections can grow quickly to consume all available client ports above 1024.
If you shut down the COM+ server application and restart it, you can free up client ports to provide relief; however, the problem recurs over time.
In certain scenarios, where it is not possible to release the remote objects, if the calls are made with different security contexts while dynamic cloaking is active, you must enable periodic RPC cleanup of the idle bindings to reduce the growing of TCP connections, given the high number of established TCP connections that is required. To achieve this, you must call the RPC RpcMgmtEnableIdleCleanup function at beginning of the client's code.
In addition, you may need to increase the available ephemeral ports on the client. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
When you encounter this problem, if you use the "netstat -n" command to examine the connections between the two computers, the output may show that all of the ephemeral ports (all ports between 1024 and 5000) on the DCOM client have been used and are in the ESTABLISHED state with a specific server's port (one above 1024). For example:
All of those TCP connections are related to COM+ proxy/stub communications. DCOM cannot recycle one of them if a thread that impersonates a new user (with dynamic cloaking active) makes a call. For example, if the client is an Internet Server Application Programming Interface (ISAPI) extension that runs on Microsoft Internet Information Server (IIS), the calls are made with the impersonation token that IIS obtained when it performed user authentication (for example, using basic authentication). In that scenario, each new IIS user token requires one or more new RPC bindings (and thus one or more new "established" TCP connections). Moreover, the number of IIS user tokens depends on the IIS token cache.
TCP 10.202.250.46:1025 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:1026 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:4997 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:4998 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:4999 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:5000 10.202.102.122:2008 ESTABLISHED
For additional information about the UserTokenTTL parameter, click the article number below to view the article in the Microsoft Knowledge Base:
RpcMgmtEnableIdleCleanup at the beginning of the client's code. However, be aware of the overhead that is necessary to re-create new, authenticated RPC bindings for the next calls.
ID articol: 301512 - Ultima examinare: 24 mar. 2009 - Revizie: 1