Socket Connect problem in UserControl hosted in IE

Got a fun one for you guys.

I have a UserControl that contains a socket that connects to our server
practically instantly when the UserControl is hosted in an executable
residing locally on a client machine. If I attempt to host this control in
Internet Explorer, the connection event takes almost exactly a minute to be
fired, after which everything is happy and connected. Now this only occurs
when one initially browses the page, as subsequent refreshes (F5s or the
little button) connect immediately.

To verify that this is a client side problem, I put 10-second-interval
heartbeats in the socket stream from the server. Sure enough, on an initial
browse and subsequent 60 second wait, the client side socket buffer contains
the six heartbeats. Upon refreshing, the buffer contains only a single
initial heartbeat. I've run the command line tool "netstat" to check the
established sockets and see only a single socket connected and have also
verified open and close events on the server.

The funkiest part? Both netstat on the client and the server (via an
attached process) show immediate established connections, but it seems like
something has delayed the first connection event to Internet Explorer. If
anyone has the slightest hint, it would be highly appreciated.

Thanks,
Willis

This might be due to an application config file download which happens when
any app using System.Net networking classes ( socket, httpwebrequest ) is
run from a browser.

If you use a network sniffer, you will see an http request go out for the
app config file. This causes the 60s delay.

You can work around this by doing a
ConfigurationSettings.GetConfig("system.net/settings") in your code before
you do any network library API call.

<sdfhsdfh> wrote in message news:ONYk14YRDHA.2144@TK2MSFTNGP11.phx.gbl...
> Got a fun one for you guys.
>
> I have a UserControl that contains a socket that connects to our server
> practically instantly when the UserControl is hosted in an executable
> residing locally on a client machine. If I attempt to host this control
in
> Internet Explorer, the connection event takes almost exactly a minute to
be
> fired, after which everything is happy and connected. Now this only
occurs
> when one initially browses the page, as subsequent refreshes (F5s or the
> little button) connect immediately.
>
> To verify that this is a client side problem, I put 10-second-interval
> heartbeats in the socket stream from the server. Sure enough, on an
initial
> browse and subsequent 60 second wait, the client side socket buffer
contains
> the six heartbeats. Upon refreshing, the buffer contains only a single
> initial heartbeat. I've run the command line tool "netstat" to check the
> established sockets and see only a single socket connected and have also
> verified open and close events on the server.
>
> The funkiest part? Both netstat on the client and the server (via an
> attached process) show immediate established connections, but it seems
like
> something has delayed the first connection event to Internet Explorer. If
> anyone has the slightest hint, it would be highly appreciated.
>
> Thanks,
> Willis
>
>

Holy easy fix batman! Thanks so much, it worked beautifully!

"feroze" <spamkhichdo@spamyahoo.com> wrote in message
news:Rr4Sa.82099$GL4.21173@rwcrnsc53...
> This might be due to an application config file download which happens
when
> any app using System.Net networking classes ( socket, httpwebrequest ) is
> run from a browser.
>
> If you use a network sniffer, you will see an http request go out for the
> app config file. This causes the 60s delay.
>
> You can work around this by doing a
> ConfigurationSettings.GetConfig("system.net/settings") in your code before
> you do any network library API call.
>
> <sdfhsdfh> wrote in message news:ONYk14YRDHA.2144@TK2MSFTNGP11.phx.gbl...
> > Got a fun one for you guys.
> >
> > I have a UserControl that contains a socket that connects to our server
> > practically instantly when the UserControl is hosted in an executable
> > residing locally on a client machine. If I attempt to host this control
> in
> > Internet Explorer, the connection event takes almost exactly a minute to
> be
> > fired, after which everything is happy and connected. Now this only
> occurs
> > when one initially browses the page, as subsequent refreshes (F5s or the
> > little button) connect immediately.
> >
> > To verify that this is a client side problem, I put 10-second-interval
> > heartbeats in the socket stream from the server. Sure enough, on an
> initial
> > browse and subsequent 60 second wait, the client side socket buffer
> contains
> > the six heartbeats. Upon refreshing, the buffer contains only a single
> > initial heartbeat. I've run the command line tool "netstat" to check
the
> > established sockets and see only a single socket connected and have also
> > verified open and close events on the server.
> >
> > The funkiest part? Both netstat on the client and the server (via an
> > attached process) show immediate established connections, but it seems
> like
> > something has delayed the first connection event to Internet Explorer.
If
> > anyone has the slightest hint, it would be highly appreciated.
> >
> > Thanks,
> > Willis
> >
> >
>
>