Re: 20 sec delay opening tcp connection from within IE hosted cont

From: Plat (Plat_at_discussions.microsoft.com)
Date: 11/08/04 

Date: Mon, 8 Nov 2004 09:25:02 -0800

I've been experiencing very similar problems, and haven't found a solution yet.

Background: I'm adapting FTP Client code similar to KB 832679, to work as an
embedded WinForm control (to run inside Internet Explorer).

I'm relatively new to .NET coding and very new to writing controls to run as
part of an Internet Explorer (IEHost?) Web page, so I apologize in advance if
I'm doing something very dumb here.

Here are some tidbits and nuances:

1) The primary problem: there is a significant delay (around 1.5 to 2
minutes) in the "Login" function where the socket connects to the server
(specifically the "m_objClientSocket.Connect(ep)" line). This delay ONLY
happens when my control is run inside IE, not when run independently inside a
regular VB.NET Form.

2) I noticed no significant network activity during, before, nor after that
extended delay (no strange DNS lookups, connection attempts, dropped packets,
malformed packets, etc).

3) If I change the ".Connect" call to ".BeginConnect" and force a timeout
(e.g. 500ms), the Socket's ".Connected" property returns True (so why is it
waiting so much longer?) My ugly code for this is something like:

            Dim ar As IAsyncResult = m_objClientSocket.BeginConnect(ep,
Nothing, 0)
            If Not ar.AsyncWaitHandle.WaitOne(m_lConnectionTimeoutMS, False)
Then
                ' connection timed out... but let's not throw an exception.
for some reason
                ' the .Connected property might be True!
            Else
                ' connected! (we hope)
            End If

            ' If we got this far and we're STILL not connected, throw
something
            If Not m_objClientSocket.Connected Then Throw New
IOException("Could not connect: connection timed out")

4) If I do the trick in #3 to avoid a long ".Connect()" block, I encounter a
similar long delay once m_objClientSocket.Receive(m_aBuffer,
m_aBuffer.Length, 0) is called, so we don't really avoid this problem.

5) Once the delay is passed, there are no more delays for that instance of
IE (not just the control instance). Future connects, receives, etc don't seem
to block; so for example if I don't do the #3 trick, the ".Connect()" blocks
for a long while, but subsequent ".Receive()" calls, etc do not block for
that instance. To re-state, when re-visiting the page through the "Back"
button, or even a separate window (using the same instance of Internet
Explorer), subsequent blocking does not occur.

6) Though I haven't tested it thoroughly, the TcpClient seems to act the
same way as using Sockets (at least, the Connect has a similar delay; I
didn't try sending/receiving data through a TcpClient).

7) I've only been able to test my code with the .NET Framework 1.1 SP1, so
I'm not sure if it acts differently in older unpatched versions.

8) The Socket does make the connection nearly immediately (I verified this
by listening to a port with netcat).

9) The code acts the same way when connecting to a variety of FTP servers on
a variety of internal and external IP addresses, and does not seem to be
affected by the IP address or hostname.

Any ideas? I can probably whip up some sample code if you need more
information.

Thanks,

Plat

"mfeingold" wrote:

> I do not think this is the case. When I comment out the TcpClient.Connect, it
> loads up and becomes functional pretty fast - withn a second. Also the winAPP
> load time is subsecond too.
> Another thng - during this delay I do not see any activity - network or
> otherwise. This is as if it is waiting for something to time-out, and when it
> does, everything just proceeds and runs ok.
>
> "Hermit Dave" wrote:
>
> > ..net control in html / aspx would need to host clr within IE and that takes
> > a lot of time... last time i read about it... someone mentioned that it
> > takes something like 16 odd secs.. that explains why your control takes 20
> > odd secs to open a tcp connection.
> >
> > the same control within winforms app doesnt take the same amount of time
> > simply because its already running in CLR hosted environment.
> >
> > i am not aware of the security configs. if i find anything on that i will
> > drop in the links later on
> >
> > --
> >
> > Regards,
> >
> > Hermit Dave (D'way)
> > http://hdave.blogspot.com
> >
> > (I hear what you're saying.. but lets try it my way first)
> >
> > "mfeingold" <mfeingold@discussions.microsoft.com> wrote in message
> > news:DCC58F62-E359-4C53-9699-2DD97A30437F@microsoft.com...
> > > I am working on a system, which among other things includes a server and a
> > > .net control sitting in an html page and connected to the server. I ran
> > into
> > > a couple of problems, you guys might have some insight about.
> > >
> > > 1) It takes 20 sec or so to open a tcp socket from the client to the
> > server.
> > > It just sits in the TcpClient.conect waiting for something. When I run the
> > > same control from a windows application it connects right away and works
> > just
> > > fine. The web based version also works fine after this initial delay. This
> > > happens both with remoting over tcp as well as direct use of sockets -
> > from
> > > within browser it takes 20 sec whereas from windows app it goes right
> > through.
> > >
> > > 2) I could not figure out how to configure security for remoting so that
> > > server can connect back to the control for callback. The problem I could
> > not
> > > figure out is that by default IE does not allow remoting from controls it
> > > hosts for obvious security reasons, so to make it work some permissions
> > > should be asserted programmatically. I know how to do this and I have done
> > > this for connection from the control to the server. The problem I could
> > not
> > > figure out is that callback objects are created by the system, not by any
> > > code I wrote so I know what code should I write but I am lost as to where
> > > should I put it.
> > >
> > >
> >
> >
> >