20 sec delay opening tcp connection from within IE hosted control

Discussion in 'ASP .Net' started by =?Utf-8?B?bWZlaW5nb2xk?=, Oct 24, 2004.

  1. 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.
    =?Utf-8?B?bWZlaW5nb2xk?=, Oct 24, 2004
    #1
    1. Advertising

  2. =?Utf-8?B?bWZlaW5nb2xk?=

    Hermit Dave Guest

    ..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" <> wrote in message
    news:D...
    > 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.
    >
    >
    Hermit Dave, Oct 24, 2004
    #2
    1. Advertising

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

    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" <> wrote in message
    > news:D...
    > > 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.
    > >
    > >

    >
    >
    >
    =?Utf-8?B?bWZlaW5nb2xk?=, Oct 24, 2004
    #3
  4. Re: 20 sec delay opening tcp connection from within IE hosted cont

    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


    "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" <> wrote in message
    > > news:D...
    > > > 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.
    > > >
    > > >

    > >
    > >
    > >
    =?Utf-8?B?UGxhdA==?=, Nov 8, 2004
    #4
  5. Re: 20 sec delay opening tcp connection from within IE hosted cont

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

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

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

    Here are some tidbits and nuances:

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

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

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

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

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

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

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

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

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

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

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


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

    Thanks,

    Plat


    "mfeingold" wrote:

    > I do not think this is the case. When I comment out the TcpClient.Connect, it
    > loads up and becomes functional pretty fast - withn a second. Also the winAPP
    > load time is subsecond too.
    > Another thng - during this delay I do not see any activity - network or
    > otherwise. This is as if it is waiting for something to time-out, and when it
    > does, everything just proceeds and runs ok.
    >
    > "Hermit Dave" wrote:
    >
    > > ..net control in html / aspx would need to host clr within IE and that takes
    > > a lot of time... last time i read about it... someone mentioned that it
    > > takes something like 16 odd secs.. that explains why your control takes 20
    > > odd secs to open a tcp connection.
    > >
    > > the same control within winforms app doesnt take the same amount of time
    > > simply because its already running in CLR hosted environment.
    > >
    > > i am not aware of the security configs. if i find anything on that i will
    > > drop in the links later on
    > >
    > > --
    > >
    > > Regards,
    > >
    > > Hermit Dave (D'way)
    > > http://hdave.blogspot.com
    > >
    > > (I hear what you're saying.. but lets try it my way first)
    > >
    > > "mfeingold" <> wrote in message
    > > news:D...
    > > > 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.
    > > >
    > > >

    > >
    > >
    > >
    =?Utf-8?B?UGxhdA==?=, Nov 8, 2004
    #5
  6. Re: 20 sec delay opening tcp connection from within IE hosted cont

    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.
    >
    > 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.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" <> wrote in message
    > > > news:D...
    > > > > 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.
    > > > >
    > > > >
    > > >
    > > >
    > > >
    =?Utf-8?B?bWZlaW5nb2xk?=, Nov 8, 2004
    #6
  7. Re: 20 sec delay opening tcp connection from within IE hosted cont

    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.
    > >
    > > 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.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" <> wrote in message
    > > > > news:D...
    > > > > > 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.
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > > >
    =?Utf-8?B?UGxhdA==?=, Nov 8, 2004
    #7
  8. Re: 20 sec delay opening tcp connection from within IE hosted cont

    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.
    > > >
    > > > 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.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" <> wrote in message
    > > > > > news:D...
    > > > > > > 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.
    > > > > > >
    > > > > > >
    > > > > >
    > > > > >
    > > > > >
    =?Utf-8?B?bWZlaW5nb2xk?=, Nov 8, 2004
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. The DUDE
    Replies:
    3
    Views:
    578
    code learner
    Dec 24, 2010
  2. Kathryn Bean
    Replies:
    1
    Views:
    679
    John Harrison
    Oct 28, 2004
  3. Tiger
    Replies:
    5
    Views:
    966
    Dave Thompson
    May 1, 2006
  4. shmuel witman

    Connection timeout (connection closing after 100 sec )

    shmuel witman, Dec 4, 2005, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    802
    shmuel witman
    Dec 6, 2005
  5. Replies:
    0
    Views:
    112
Loading...

Share This Page