Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > 20 sec delay opening tcp connection from within IE hosted control

Reply
Thread Tools

20 sec delay opening tcp connection from within IE hosted control

 
 
=?Utf-8?B?bWZlaW5nb2xk?=
Guest
Posts: n/a
 
      10-24-2004
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.


 
Reply With Quote
 
 
 
 
Hermit Dave
Guest
Posts: n/a
 
      10-24-2004
..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" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> 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.
>
>



 
Reply With Quote
 
 
 
 
=?Utf-8?B?bWZlaW5nb2xk?=
Guest
Posts: n/a
 
      10-24-2004
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" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed)...
> > 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.
> >
> >

>
>
>

 
Reply With Quote
 
=?Utf-8?B?UGxhdA==?=
Guest
Posts: n/a
 
      11-08-2004
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.

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.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" <(E-Mail Removed)> wrote in message
> > news(E-Mail Removed)...
> > > 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.
> > >
> > >

> >
> >
> >

 
Reply With Quote
 
=?Utf-8?B?UGxhdA==?=
Guest
Posts: n/a
 
      11-08-2004
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.

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" <(E-Mail Removed)> wrote in message
> > news(E-Mail Removed)...
> > > 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.
> > >
> > >

> >
> >
> >

 
Reply With Quote
 
=?Utf-8?B?bWZlaW5nb2xk?=
Guest
Posts: n/a
 
      11-08-2004
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);

"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_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.
>
> 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.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" <(E-Mail Removed)> wrote in message
> > > news(E-Mail Removed)...
> > > > 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.
> > > >
> > > >
> > >
> > >
> > >

 
Reply With Quote
 
=?Utf-8?B?UGxhdA==?=
Guest
Posts: n/a
 
      11-08-2004
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.Reflection.Assembly.GetExecutingAssembly(). CodeBase.Replace(".dll",
> ".aspx");
> HttpWebRequest request = (HttpWebRequest)WebRequest.Create(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_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.
> >
> > 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.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" <(E-Mail Removed)> wrote in message
> > > > news(E-Mail Removed)...
> > > > > 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.
> > > > >
> > > > >
> > > >
> > > >
> > > >

 
Reply With Quote
 
=?Utf-8?B?bWZlaW5nb2xk?=
Guest
Posts: n/a
 
      11-08-2004
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.Reflection.Assembly.GetExecutingAssembly(). CodeBase.Replace(".dll",
> > ".aspx");
> > HttpWebRequest request = (HttpWebRequest)WebRequest.Create(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_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.
> > >
> > > 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.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" <(E-Mail Removed)> wrote in message
> > > > > news(E-Mail Removed)...
> > > > > > 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.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Long 2 sec Delay opening desktop toolbar? network? lbbss Computer Support 0 03-23-2007 01:56 AM
Re: Upgrade path: MCSA2000:Sec -> MCSA2003 -> MCSE2003:Sec ? The Rev [MCT] MCSE 0 12-13-2005 12:22 PM
Re: Upgrade path: MCSA2000:Sec -> MCSA2003 -> MCSE2003:Sec ? Bob Christian MCSE 1 12-13-2005 08:36 AM
No PAT from Higher Sec to Lower Sec interface Clemens Schwaighofer Cisco 0 10-20-2005 10:18 AM
Upgrade path: MCSA2000:Sec -> MCSA2003 -> MCSE2003:Sec ? =?Utf-8?B?QW1hbiBCLg==?= MCSE 4 09-07-2005 06:55 PM



Advertisments