473,699 Members | 2,377 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

20 sec delay opening tcp connection from within IE hosted control

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.conec t 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 programmaticall y. 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.
Nov 18 '05 #1
7 2936
..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" <mf*******@disc ussions.microso ft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.

Nov 18 '05 #2
I do not think this is the case. When I comment out the TcpClient.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.


Nov 18 '05 #3
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_objClientSoc ket.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 ".BeginConn ect" 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_objClientSock et.BeginConnect (ep,
Nothing, 0)
If Not ar.AsyncWaitHan dle.WaitOne(m_l ConnectionTimeo utMS, 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_objClientSock et.Connected Then Throw New
IOException("Co uld 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_objClientSock et.Receive(m_aB uffer,
m_aBuffer.Lengt h, 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
"mfeingold" wrote:
I do not think this is the case. When I comment out the TcpClient.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.


Nov 18 '05 #4
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_objClientSoc ket.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 ".BeginConn ect" 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_objClientSock et.BeginConnect (ep,
Nothing, 0)
If Not ar.AsyncWaitHan dle.WaitOne(m_l ConnectionTimeo utMS, 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_objClientSock et.Connected Then Throw New
IOException("Co uld 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_objClientSock et.Receive(m_aB uffer,
m_aBuffer.Lengt h, 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.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.


Nov 18 '05 #5
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.Reflecti on.Assembly.Get ExecutingAssemb ly().CodeBase.R eplace(".dll",
".aspx");
HttpWebRequest request = (HttpWebRequest )WebRequest.Cre ate(loaderPage) ;

"Plat" wrote:
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_objClientSoc ket.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 ".BeginConn ect" 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_objClientSock et.BeginConnect (ep,
Nothing, 0)
If Not ar.AsyncWaitHan dle.WaitOne(m_l ConnectionTimeo utMS, 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_objClientSock et.Connected Then Throw New
IOException("Co uld 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_objClientSock et.Receive(m_aB uffer,
m_aBuffer.Lengt h, 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
"mfeingold" wrote:
I do not think this is the case. When I comment out the TcpClient.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.
>
>

Nov 18 '05 #6
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.

"mfeingold" wrote:
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.Reflecti on.Assembly.Get ExecutingAssemb ly().CodeBase.R eplace(".dll",
".aspx");
HttpWebRequest request = (HttpWebRequest )WebRequest.Cre ate(loaderPage) ;

"Plat" wrote:
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_objClientSoc ket.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 ".BeginConn ect" 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_objClientSock et.BeginConnect (ep,
Nothing, 0)
If Not ar.AsyncWaitHan dle.WaitOne(m_l ConnectionTimeo utMS, 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_objClientSock et.Connected Then Throw New
IOException("Co uld 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_objClientSock et.Receive(m_aB uffer,
m_aBuffer.Lengt h, 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
"mfeingold" wrote:
I do not think this is the case. When I comment out the TcpClient.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
> news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.
> >
> >
>
>
>

Nov 18 '05 #7
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.

"Plat" wrote:
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.

"mfeingold" wrote:
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.Reflecti on.Assembly.Get ExecutingAssemb ly().CodeBase.R eplace(".dll",
".aspx");
HttpWebRequest request = (HttpWebRequest )WebRequest.Cre ate(loaderPage) ;

"Plat" wrote:
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_objClientSoc ket.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 ".BeginConn ect" 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_objClientSock et.BeginConnect (ep,
Nothing, 0)
If Not ar.AsyncWaitHan dle.WaitOne(m_l ConnectionTimeo utMS, 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_objClientSock et.Connected Then Throw New
IOException("Co uld 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_objClientSock et.Receive(m_aB uffer,
m_aBuffer.Lengt h, 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
"mfeingold" wrote:

> I do not think this is the case. When I comment out the TcpClient.Conne ct, 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" <mf*******@disc ussions.microso ft.com> wrote in message
> > news:DC******** *************** ***********@mic rosoft.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.conec t 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 programmaticall y. 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.
> > >
> > >
> >
> >
> >

Nov 18 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1546
by: Lecture Snoddddgrass | last post by:
Hi, I noticed that my WinForms app was taking a while to start up. I stepped through the code to find out which line was causing the delay. The delay is occurring within one of my UserControls whose designer-generated InitializeComponent() method instantiates a web browser control and eventually calls EndInit() on it. It's that EndInit() call that takes several seconds to complete. What's odd is that my application makes extensive use...
2
1590
by: c5kirk | last post by:
Hi there. I'm new to .Net development and have inherited a web project built using .Net and C#. I have a copy of the project on my laptop machine and can open it, make changes, compile fine, test, etc... The previous developer had VS.Net installed on the web server that the application is hosted on and would make changes, compile, etc... directly on that machine. However, when I try to open the project within VS.Net on that machine I get a...
20
3017
by: Doug Thews | last post by:
I ran into an interesting re-pain delay after calling the Abort() method on a thread, but it only happens the very first time I call it. Every time afterward, there is no delay. I've got a delegate inside the UI that I call to update the progress meter. I use the Suspend() and Abort() methods based on button events. I can watch the progress meter increase just fine when the thread is running. When I select Start, I enable the Cancel...
0
1410
by: Tom Stepka | last post by:
Problem: We are experiencing an excessive (i.e. 16 - 20 seconds) delay when attempting to establish socket connection over the network, using the TcpLister.AcceptSocket() and TcpClient.Connect(ipAddress, Port) calls. It seems that the delay is between client.Connect() and listener.Accept(). We never have a delay when we use a telnet client to connect to the server. And we do not have a delay on all networks, just on some. The code we...
0
1001
by: mg | last post by:
When I'm connected to a remote network via a VPN connection and open a WebForm project, I experience a considerable delay. During this delay, an "Initializing offline cache" message appears in the bottom bar of VS .NET. Is there some way of speeding up this project opening?
0
1308
by: Paul | last post by:
I'm trying to use a socket connection from within an asp.net application. It works, but somehow opening the socket seems to be extremely slow. It finally connects and you can transfer information, but it hangs for at least 5 seconds before the connection completes. Interestingly, a second connection to the same port in a very short time interval (<1s) returns instantly, but if you wait for a couple of seconds a new connection again takes...
5
2026
by: Burton Roberts | last post by:
When using ASP.NET and an OleDBConnection control I get this error on CNN.Open: "The Microsoft Jet database engine cannot open the file 'C:\A2K\Backups\EdsBe2K.mdb'. It is already opened exclusively by another user, or you need permission to view its data." I have tried using a connection string, too, to no avail. However, when I am in Windows Forms I have no problem opening the same file
3
2612
by: lopedon | last post by:
I've got a performance issue in Access 2000 running on Windows 2000. Opening a table local to the MDB takes about 1-2 seconds normally. If I log out of the windows profile that is normally used on the machine and log into another windows profile, the same table in the same MDB file takes 6 seconds to open. I have tried setting the subdatasheet property to and turning autocorrect off, neither one changes anything. Doing a compact/repair...
1
6497
by: leshka82 | last post by:
I have recently designed a Winform Image drag & drop utility. The approach I took was to have a Panel control serve as a destination for multiple file drop. Once the user dragged & dropped the desired files I do a check to ensure that I only process the image files (".jpg", ".png", etc), while any other files are ignored by the program. For every image file being dropped I programmatically create a PictureBox control, do proper resizing of an...
0
8621
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9184
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
8929
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8891
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7759
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5878
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4380
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3061
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
2013
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.