20 sec delay opening tcp connection from within IE hosted control

G

Guest

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.
 
H

Hermit Dave

..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)
 
G

Guest

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.
 
G

Guest

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 for your help,

Plat
 
G

Guest

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
 
G

Guest

Yea, it seems to be a problem with IP stack initialization within IE. The
problem manifests itself when you try to connect the first time - TCP or UDP
does not matter. I found a workaround it but it beats me why this way is any
better than any other.

Here it is: the following 2 lines, initialize the stack without any delays.

string loaderPage =
System.Reflection.Assembly.GetExecutingAssembly().CodeBase.Replace(".dll",
".aspx");
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(loaderPage);
 
G

Guest

Hey, cool, it works! Brilliant. Thanks for the quick reply.

Still, this definitely feels like a kludge. Are you aware of any official
workaround, patch, or KB article regarding this problem? Maybe I'm looking in
the wrong places, but I haven't seen anything.

In the meantime, thanks much for the workaround! I'm baffled as to why it
works, but I'm not seeing any additional network overhead, so I can't
complain much.

Tyler

PS - Sorry for the duplicate posts - I wasn't aware it would be posted
twice; my first post resulted in a "we encountered an unexpected error.."
message on the MSDN site.
 
G

Guest

I could not find anything either. But on the other hand I do not believe that
we are the first ones to experience this problem. I will probably repost the
qustion with the workaround. Hopefully it will attract attention of somebody
who actually knows what's going on.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top