From: Esther Klijnsma (E.KlijnsmaODT.NL)
Date: Wed Mar 19 2003 - 02:36:53 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Goedemorgen Henk,

Eerlijk gezegd behoorlijk technisch voor mij op de vroege morgen ;-).
We doen niet aan NAT, en het enige wat ik kan bedenken is dat de route
richting de VPN is vormgegeven via een gateway of last resort in de router
(ipv een directe route naar het adres).
Ik kan me niet voorstellen dat er pakketjes een adres zouden zoeken wat niet
bereikbaar is: alles gaat volgens mij naar dezelfde remote machine. Zelfs

-----Oorspronkelijk bericht-----
Van: Henk de Koning [mailto:henkkCOMPLEXIT.COM]
Verzonden: woensdag 19 maart 2003 21:25
Aan: DCOMDISCUSS.MICROSOFT.COM
Onderwerp: Re: Dcom connection delay with NT connecting to NT

Wow, it's been ages since I last worked with this COM on NT4. No, let me
correct that, it's been ages since I worked with COM ;-). I'm probably the
only dinosaur left who was on this list right after it was founded (I think
Phil's been on here for a while too).

Anyhow, I can only guess. You're not doing NAT are you ? Let me explain how
DCOM sets up a connection. When the client recieves a marshaled object,
refered to as an objref or a MEOW packet, it'll go and do something called
OXID resolution. On NT4 an OXID basically refers to an apartment. Each
apartment is sort of a mini RPC server, although on NT4 they all share the
same portno. OXID resolution is the process of translating the OXID in the
MEOW packet to a valid rpc string binding. First the client checks the local
OXID resolver (who has a cache of all OXIDs it saw previously), when nothing
is found the local OXID resolver contacts the remote (server) OXID resolver
(which lives in the same process and listens to the same port as the
endpoint mapper -- port 135). It finds the remote OXID resolver by checking
the adress/protseq combos in the MEOW packet. It'll follow all of them in
the order in which they are listed in the MEOW packet. So, if any of those
addresses are not reachable (because the router is not aware of them and
routes them the wrong way) this will explain your delays.

Is the machine multihomed ?

BTW, on Win2K the whole binding process is totally different and allthough
OXIDs still exist, most of their old role is taken over by APPIDs. The
activation stuff is now a COM interface as well. This explains why on Win2K
you don't see the delays.

-- Henkk

----- Original Message -----
From: "Esther" <e.klijnsmaODT.NL>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Tuesday, March 18, 2003 12:53 PM
Subject: Re: Dcom connection delay with NT connecting to NT

> Thanks,
>
> Indeed, if we tried logging on without the 'impersonate' option, but
> instead with anonymous, we didn't get the event log item.
>
> As to the problem of the delay, we found out that somehow NT doesn't like
a
> setup with a router - Pix - Pix - Router.
> If we tried the connection directly (from Pix- to pix, without the router)
> there was no problem whatsoever. If we included the router, with NT4, the
> connection was slow (delay of 50s.) This is only the case in NT (with 2000
> it worked fine).
>
> Do you know anything about that DCOm is not routable?
>
>
> On Fri, 14 Mar 2003 05:14:44 +0100, Henk de Koning <henkkCOMPLEXIT.COM>
> wrote:
>
> >Sniff the network. The most likely cause for this is authentication. One
of
> >the fun things of DCOM is that on NT4 CoCreateInstanceEx will revert to
an
> >RPC interface called IRemoteActivation to do the actual object creation
on
> >the server. For authentication of that call (regardless of the watermarks
> >set on your proxies) DCOM will first try all registered protocols using
> >authentication and only when they all fail turn authentication off for
the
> >activation call. Usually that explains the delay.
> >
> >If this is the cause, you can use the AUTHINFO part of the COSERVERINFO
> >structure to disable authentication for activation calls. Note that this
> can
> >only be done from an environment that actually has access to CCIEx (like
> >C++).
> >
> >-- Henkk
> >
> >----- Original Message -----
> >From: "Esther Klijnsma" <helpdeskODT.NL>
> >To: <DCOMDISCUSS.MICROSOFT.COM>
> >Sent: Wednesday, March 05, 2003 6:33 PM
> >Subject: Dcom connection delay with NT connecting to NT
> >
> >
> >> Hi all,
> >>
> >> I have a very big problem by now with DCOM connections. The situation
is
> >as
> >> follows: In our network (location A) we have an NT-infrastructure (NT4,
> >> SP6a). The Server to which we connect with the program is located
> >somewhere
> >> else(location B), we connect throug a VPN. On both locations we also
have
> >> an internal router. The thing is: the server on location B is NT 4. All
> >> clients in different parts of the world connecting to server on
location
> B
> >> have no problem, except us. All clients use Windows 95,98,2000,XP,
except
> >> us (we use NT). They tried out a client with win NT on location B and
it
> >> had no problems. So i think along the lines of the UDP preference of NT
> as
> >> the cause of the problem (explaining why we have the problems and
no-one
> >> else), but the thing is: it should only be the first time connecting,
and
> >> not afterwards (if i understand the microsoft technotes correctly). And
> in
> >> our case every module in the program (GUI) you open has at least a 45
> >> second delay. We tried with XP and 98 in our office (location A) and
they
> >> connect in about 7 seconds, and can open all the modules just as fast.
> The
> >> thing is: we removed every protocol except TCP/IP from the dcomcnfg,
and
> >it
> >> still is the same. Even worse: with only TCP present, or with all
> >protocols
> >> present in dcomcnfg, we get the event log nr. 10009 from DCOM stating
it
> >> cannot connect to the server (in location B) using any of the
configured
> >> protocols. I'm at a loss here, don't even know in which direction to
> think
> >> any more. Can anyone help me out here? (migrating to win2000 or win2k
is
> >> not an option for the near future).
> >>
> >> Thanks so much.
> >> Esther
> >>
> >> ----------------------------------------------------------------
> >> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> >> contains important info. Save time, search the archives at
> >> http://discuss.microsoft.com/archives/index.html .
> >> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> >>
> >
> >----------------------------------------------------------------
> >Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> >contains important info. Save time, search the archives at
> >http://discuss.microsoft.com/archives/index.html .
> >To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]