Slow TCP connection from IE

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a problem with TCP connections from controls embedded in HTML pages.

The client-application is a (.NET) usercontrol embedded in an HTML page (viewed using IE).

When the client calls:

Dim client As New System.Net.Sockets.TcpClient(_hostname, _port)

while at the same time the server calls:

i = stream.Read(bytes, 0, bytes.Length)

it takes _exactly_ 100 seconds the first time – subsequent calls are immediate.

It looks like it’s a timeout – but of what?!? – after all: I get the correct result; no problem there. Using TDImon fra SysInternals I can se that at the first (and very slow) communication, IE initially communicates at port 80 - but I havn't got a clue why. I have wondered whether it could be a DNS error, but the host I communicate to is localhost so I think that would be a rather strange reason. The problem has been verified in different organisations using several independently installed PC's.

When the client control is placed in a winform instead of in a HTML page, there is no performance problem at all.

I have a small, clean and to the point VS-solution which demonstrates the problem if anybody is interested. It consists of the control project, a winforms client, a html page and a tcp-server project.

I am sure that this is expected behaviour – just no for me or anyone that has looked at it… ;^(


Regards

Henrik
 
I am currently using synchronous connects, writes and reads but I have tried doing it asynchronously too using the System.Net.Sockets.Socket class (after your posting) but unfortunately with the same result

If you want to try it out for yourself I have put a simple, clean and to the point zip-file at http://www.captator.dk/downloads/TcpConnection.zi

Regard

Henri

----- Chad Z. Hower aka Kudzu wrote: ----

=?Utf-8?B?SGVucmlr?= said:
it takes _exactly_ 100 seconds the first time “ subsequent calls ar
immediate.
Click to expand...

Are you using blocking or non blocking sockets


-
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu
"Programming is an art form that fights back


ELKNews - Get your free copy at http://www.atozedsoftware.co
 
=?Utf-8?B?SGVucmlr?= said:
I am currently using synchronous connects, writes and reads but I have
tried doing it asynchronously too using the System.Net.Sockets.Socket
class (after your posting) but unfortunately with the same result.
Click to expand...

I dont know - but it sounds either code or system specific.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Not a vb guy. But I think I remember something similar testing server and
client on same box. I would narrow it down from simple things to test for
first. 1) try a sleep after the client sends its first data. This should
give the server thread a chance to get the connect. 2) try server on one
box1 and client on another box. If it works fast, then you know it has
something to do with testing on same box. You can then also use NetMon to
see what is going on (i.e. dns, connection timeouts, etc.) on the wire. hth

--
William Stacey, MVP

Henrik said:
I have a problem with TCP connections from controls embedded in HTML pages.

The client-application is a (.NET) usercontrol embedded in an HTML page (viewed using IE).

When the client calls:

Dim client As New System.Net.Sockets.TcpClient(_hostname, _port)

while at the same time the server calls:

i = stream.Read(bytes, 0, bytes.Length)

it takes _exactly_ 100 seconds the first time - subsequent calls are immediate.

It looks like it's a timeout - but of what?!? - after all: I get the
Click to expand...
correct result; no problem there. Using TDImon fra SysInternals I can se
that at the first (and very slow) communication, IE initially communicates
at port 80 - but I havn't got a clue why. I have wondered whether it could
be a DNS error, but the host I communicate to is localhost so I think that
would be a rather strange reason. The problem has been verified in different
organisations using several independently installed PC's.
When the client control is placed in a winform instead of in a HTML page,
Click to expand...
there is no performance problem at all.
I have a small, clean and to the point VS-solution which demonstrates the
Click to expand...
problem if anybody is interested. It consists of the control project, a
winforms client, a html page and a tcp-server project.
 
Back
Top