Continued problem with Socket in User Control in IE

Hey guys (and ladies),

To get started, all of this is going to be run under Full Trust permissions,
so I know that it isn't a security problem.

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.

Finally, any web service calls that are made during this socket connection
window are also hung up. If these calls are made during times when the
socket is not attempting a connection, the calls go through in expected
amounts of time. This is the case even if the call is made when the page is
initially loaded for the first time.

If anyone has the slightest hint, it would be highly appreciated.

Thanks,
Willis

Chris
Mon Jul 21 10:52:33 CDT 2003

Problem fixed. Thanks!

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.


"Chris Willis" <cwillis@matrixgroup.com> wrote in message
news:uXVwHKhSDHA.1552@TK2MSFTNGP12.phx.gbl...
> Hey guys (and ladies),
>
> To get started, all of this is going to be run under Full Trust
permissions,
> so I know that it isn't a security problem.
>
> 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.
>
> Finally, any web service calls that are made during this socket connection
> window are also hung up. If these calls are made during times when the
> socket is not attempting a connection, the calls go through in expected
> amounts of time. This is the case even if the call is made when the page
is
> initially loaded for the first time.
>
> If anyone has the slightest hint, it would be highly appreciated.
>
> Thanks,
> Willis
>
>