Async socket & active connections

[atlaste]

Hi,

In an attempt to create a full-blown webcrawler I've found myself
writing a wrapper around the Socket class in an attempt to make it
completely async, supporting timeouts and some scheduling mechanisms.
I use a non-blocking approach for this, using the call to 'poll' to
support the async mechanism - rather than the 'begin' and 'end'
functions. I already found that connecting doesn't set the
"isconnected" variable correctly (SocketException is thrown: non-
blocking has this effect...) - but doesn't appear to be a problem
because poll, read and write work fine.

For measuring the performance of the crawler, I started "perfmon.msc"
and added the "active connections" item from object "TCP". After a
while I found the number of this performance counter to reach over
300K connections (!), enough to start worrying...

My crawler is designed to support around 200 connections simultaneous.
"netstat -an" doesn't support this finding, but does show hundreds of
connections that are in either "CLOSE_WAIT", "FIN_WAIT_2" or another
closing state.

After a host has completed, I try to disconnect the TCP/IP connection.
I've attempted combinations of "shutdown(both)", (async) "disconnect"
and "close(0)" - where no combination appears to have the desired
effect. When the application is shut down, all connections (including
the CLOSE_WAIT connections) are removed. The FIN_WAIT_2 connections
linger forever...

Perhaps someone knows a solution to this problem?

Greetings,

Stefan de Bruijn.

 

[DeveloperX]

Hi,

In an attempt to create a full-blown webcrawler I've found myself
writing a wrapper around the Socket class in an attempt to make it
completely async, supporting timeouts and some scheduling mechanisms.
I use a non-blocking approach for this, using the call to 'poll' to
support the async mechanism - rather than the 'begin' and 'end'
functions. I already found that connecting doesn't set the
"isconnected" variable correctly (SocketException is thrown: non-
blocking has this effect...) - but doesn't appear to be a problem
because poll, read and write work fine.

For measuring the performance of the crawler, I started "perfmon.msc"
and added the "active connections" item from object "TCP". After a
while I found the number of this performance counter to reach over
300K connections (!), enough to start worrying...

My crawler is designed to support around 200 connections simultaneous.
"netstat -an" doesn't support this finding, but does show hundreds of
connections that are in either "CLOSE_WAIT", "FIN_WAIT_2" or another
closing state.

After a host has completed, I try to disconnect the TCP/IP connection.
I've attempted combinations of "shutdown(both)", (async) "disconnect"
and "close(0)" - where no combination appears to have the desired
effect. When the application is shut down, all connections (including
the CLOSE_WAIT connections) are removed. The FIN_WAIT_2 connections
linger forever...

Perhaps someone knows a solution to this problem?

Greetings,

Stefan de Bruijn.

Just a guess, can you try it with keepalive set to 0?

Something like where s is a Socket:

s.SetSocketOption(System.Net.Sockets.SocketOptionLevel.IP,
System.Net.Sockets.SocketOptionName.KeepAlive, 0);

 

[atlaste]

Thanks for your reaction.

It is my understanding from TCP/IP keepalive have a different meaning
(see http://msdn.microsoft.com/library/d...winsock/winsock/sol_socket_socket_options.asp
and http://msdn2.microsoft.com/en-us/library/system.net.sockets.socketoptionname.aspx
) than what you would suggest. Setting it to "true" should close the
connection after 2 hours or something like that. (Since two hours
sounds like "a lifetime" to me, I can see where the name "keepalive"
originated

So while it actually sound like a good idea to set it to true -
doesn't really solve my problem I'm afraid.

Perhaps someone has another suggestion?

Cheers,
Stefan de Bruijn.

 

[DeveloperX]

Thanks for your reaction.

It is my understanding from TCP/IP keepalive have a different meaning
(seehttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/wins...
andhttp://msdn2.microsoft.com/en-us/library/system.net.sockets.socketopt...
) than what you would suggest. Setting it to "true" should close the
connection after 2 hours or something like that. (Since two hours
sounds like "a lifetime" to me, I can see where the name "keepalive"
originated

So while it actually sound like a good idea to set it to true -
doesn't really solve my problem I'm afraid.

Perhaps someone has another suggestion?

Cheers,
Stefan de Bruijn.






- Show quoted text -

Ah yes I see, how about changing the Linger option?

Basically the suggestion comes because of something I read about
Apache changing a method to close connections too become Linger_Close
and it caused lots of FIN_WAIT_2 issues for people.

Again, just an idea

 

[atlaste]

Yes, that was what I expected as well. As soon as a connection is
established I do a:

socket.LingerState.Enabled = false

I even set SocketOptionName.DontLinger to true just to be sure No
luck.

The disconnection procedure is currently as follows:

- dontlinger -> true
- lingerstate.enabled = false;
- socket.Shutdown(both);
- socket.begindisconnect(some callback)
and in the callback:
- socket.enddisconnect()
- socket.close(1);

I set the close timeout to 1 second because I want to avoid some fancy
rule that makes 0 an exception resulting in endless lingering and so
on.

So far no luck... Oh and I still get FIN_WAIT_2 states. (which
shouldn't be happening afaik)

Perhaps it helps if I provide a little more code about the connection
procedure:

---
private Socket socket;
private bool Connected = false;

public void Connect(IPAddress ip, int port)
{
socket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
socket.Blocking = false;

try { socket.Connect(ip, port); }
catch (SocketException) { } // non-blocking
}

public bool IsConnected()
{
// NOTE: because of a bug in the .NET framework, we can't
use the "isconnected"
// property.

if (Connected == false && socket != null)
{
if (socket.Poll(0, SelectMode.SelectWrite))
{
socket.LingerState.Enabled = false;
Connected = true;
}
}
return Connected;
}

 

[atlaste]

The major problem I'm currently facing is that my complete internet
connection just dies I've ruled out every option where the modem(s)
or ISP is involved - so that leaves me with the software itself.

I've attempted to disassemble the socket class with Reflector in a
last resort. There I found that the m_IsConnected property is used in
various methods - among others "SetToDisconnected" and
"UpdateStatusAfterSocketError". However, I cannot find a direct cause
of my problems. (the members that don't get updated because of the
IsConnected bug are m_RightEndPoint, m_IsConnected and
m_IsDisconnected).

Can someone please confirm that this is the source of all this pain
and misery?

I've posted this message in other discussion groups as well, because
the problem doesn't solely concern C# but .NET in general.

Greetings,
Stefan.

 

[Guest]

Stefan,
I don't understand why the effort to (in some ways) "reinvent the wheel",
but I've written what I believe are very efficient webcrawlers using the
built-in asynchronous methods without any of the nasty side effects you
describe. Timeouts can be added if necessary.
Peter

 

[atlaste]

Well actually I have tried the async methods of webrequest, libcurl,
libwww and some other solutions. I am well aware of the capabilities
of those implementations.

Perhaps not so needless to say is that I don't merely concentrate my
efforts on http/web, but also on other protocols (which aren't so well
supported). I chose the example of a webcrawler because it is in my
opinion a good example of the amount of distribution and connections
that I'm looking for. Furthermore I'd like to compare the different
methods to evaluate them and simply pick the best method for my
purposes.

Reinventing the wheel or not and discussing if I'm doing that or not
isn't really what I would like to debate. The fact remains that the
whole network traffic just shuts down with my tcp wrapper class, which
just shouldn't happen in any case.

Thanks,

Stefan.

 

[DeveloperX]

Well actually I have tried the async methods of webrequest, libcurl,
libwww and some other solutions. I am well aware of the capabilities
of those implementations.

Perhaps not so needless to say is that I don't merely concentrate my
efforts on http/web, but also on other protocols (which aren't so well
supported). I chose the example of a webcrawler because it is in my
opinion a good example of the amount of distribution and connections
that I'm looking for. Furthermore I'd like to compare the different
methods to evaluate them and simply pick the best method for my
purposes.

Reinventing the wheel or not and discussing if I'm doing that or not
isn't really what I would like to debate. The fact remains that the
whole network traffic just shuts down with my tcp wrapper class, which
just shouldn't happen in any case.

Thanks,

Stefan.



- Show quoted text -

I couldn't reproduce it, but I can only do it at home as I've only got
access to 1.1 in the office and the Socket implementation is
different. Can you reproduce it in a tiny bit of code, ie just create
a socket, set the options, connect to a URL retrieve a bit of data and
close it? That's what I tried last night. I even tried things like not
closing the socket and so forth and couldn't get a FIN_WAIT_2.
Interesting problem though, networking in general is fascinating imo.

 

[atlaste]

Lazy as I am, I haven't created a minimal testcase. Okay, that's not
really true... I just don't know how to create one, since I'm doing
terrible things with the sockets api, that I don't really know how to
reproduce in a proper context (read: without getting angry faces).

I did attempt to use async methods of socket, like Peter suggested.
Furthermore I keep track of TCP connect and disconnect operations in a
performance counter just to make sure no resource is
"leaking" (although that shouldn't be a problem in a GC'ed language
you could but shouldn't think...).

Funny enough the approach did help me somewhat. That said, I have to
elaborate on that:

I nowadays rely on the begin/end methods of connect and send. For the
disconnect operation I use the following sequence:

socket.LingerState = new LingerOption(true, 0);
socket.Shutdown(SocketShutdown.Both);
socket.Close(0);

See http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.lingerstate.aspx
for an explanation of the lingerstate I set during the way.

The usual behaviour is that *any* TCP socket operation on the pc just
fries. So it looks like the resources are slowly drained. The program
actually seems to work for a random amount of time; which supports the
theory, since not every host needs the same processing. I went back to
my log files and tried to find a pattern that matches the behaviour of
the program. It seems that the behaviour is not really random (!), but
rather magically has something to do with a factor (of connected/
disconnected) close to 61000.

.... why does that remind me of 2^16, which is usually the number of
file descriptors?

I currently try setting the socket back to blocking mode before
setting the lingerstate because I want to avoid that setting to affect
the socket behaviour (although it shouldn't). I should have the
results in about .. 4 hours or so... I hope this will end my long
journey of creating a "simple" TCP/IP client.

Cheers,
Stefan de Bruijn.

 

[atlaste]

Yes!

The "blocking = true" in the disconnect phase seems to solve the
problem. Oddly enough.

So I took Lutz' reflector and started browsing through the code of
Socket and TcpClient (which I don't use), till I found some strange
things. First there's the code of System.Net.Socket.Dispose(bool)
(called from Close(int)). Once the dispose process is starting, the
"disposing" part of this method starts to kick in, trying to force a
blocking connection somewhere down the line. To be honest I can't find
a reason why this done, but I'm sure it's there for a reason. Funny
enough I set the close timeout to 0, so that particular line of code
is never hit (and if it was, then I'm quite confident the winsock2 api
will return a 'disconnected' error due to the shutdown).

The second thing I noticed is that the cleanup procedure for 0 timeout
and the procedure for non-0 timeout is quite different. In this case
it would mean 'shudown' is required for a Close(0), but not for a
Close(1). I can see now why the shutdown is a good idea for proper
programming.

Another difference I've spotted is in the closing in TcpClient and
Socket. The former calls "InternalShutdown", while the latter calls
"Shutdown". The latter is the call to shutdown which we (normal users)
use on socket as well to close both ends of the connection (i.e.
mysocket.Shutdown(SocketShutdown.Both). So I grabbed the
documentation of shutdown: http://msdn2.microsoft.com/en-us/library/ms740481.aspx
- which explicitly states a call to "closesocket" should be placed -
which in turn is responsive to blocking mode.

Funny enough I can't find a call to 'closesocket' anywhere... strange
isn't it?

Anyways, I'm 50% confident that this problem is solved. The other 50%
concerns about the closesocket call. Furthermore I wonder if this is a
MS bug or desired behaviour. And while wondering I strongly feel that
it would be very nice if someone would be kind enough to create a
couple of small examples (blocking, non-blocking, polling) of proper
socket programming.

Cheers,
Stefan de Bruijn.

Lazy as I am, I haven't created a minimal testcase. Okay, that's not
really true... I just don't know how to create one, since I'm doing
terrible things with the sockets api, that I don't really know how to
reproduce in a proper context (read: without getting angry faces).

I did attempt to use async methods of socket, like Peter suggested.
Furthermore I keep track of TCP connect and disconnect operations in a
performance counter just to make sure no resource is
"leaking" (although that shouldn't be a problem in a GC'ed language
you could but shouldn't think...).

Funny enough the approach did help me somewhat. That said, I have to
elaborate on that:

I nowadays rely on the begin/end methods of connect and send. For the
disconnect operation I use the following sequence:

socket.LingerState = new LingerOption(true, 0);
socket.Shutdown(SocketShutdown.Both);
socket.Close(0);

Seehttp://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.li...
for an explanation of the lingerstate I set during the way.

The usual behaviour is that *any* TCP socket operation on the pc just
fries. So it looks like the resources are slowly drained. The program
actually seems to work for a random amount of time; which supports the
theory, since not every host needs the same processing. I went back to
my log files and tried to find a pattern that matches the behaviour of
the program. It seems that the behaviour is not really random (!), but
rather magically has something to do with a factor (of connected/
disconnected) close to 61000.

... why does that remind me of 2^16, which is usually the number of
file descriptors?

I currently try setting the socket back to blocking mode before
setting the lingerstate because I want to avoid that setting to affect
the socket behaviour (although it shouldn't). I should have the
results in about .. 4 hours or so... I hope this will end my long
journey of creating a "simple" TCP/IP client.

Cheers,
Stefan de Bruijn.

Well actually I have tried the async methods of webrequest, libcurl,
libwww and some other solutions. I am well aware of the capabilities
of those implementations.
Perhaps not so needless to say is that I don't merely concentrate my
efforts on http/web, but also on other protocols (which aren't so well
supported). I chose the example of a webcrawler because it is in my
opinion a good example of the amount of distribution and connections
that I'm looking for. Furthermore I'd like to compare the different
methods to evaluate them and simply pick the best method for my
purposes.
Reinventing the wheel or not and discussing if I'm doing that or not
isn't really what I would like to debate. The fact remains that the
whole network traffic just shuts down with my tcp wrapper class, which
just shouldn't happen in any case.
Thanks,
Stefan.
On Mar 28, 3:13 am, Peter Bromberg [C# MVP]
Stefan,
I don't understand why the effort to (in some ways) "reinvent the wheel",
but I've written what I believe are very efficient webcrawlers using the
built-in asynchronous methods without any of the nasty side effects you
describe. Timeouts can be added if necessary.
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
:
Hi,
In an attempt to create a full-blown webcrawler I've found myself
writing a wrapper around the Socket class in an attempt to make it
completely async, supporting timeouts and some scheduling mechanisms.
I use a non-blocking approach for this, using the call to 'poll' to
support the async mechanism - rather than the 'begin' and 'end'
functions. I already found that connecting doesn't set the
"isconnected" variable correctly (SocketException is thrown: non-
blocking has this effect...) - but doesn't appear to be a problem
because poll, read and write work fine.
For measuring the performance of the crawler, I started "perfmon.msc"
and added the "active connections" item from object "TCP". After a
while I found the number of this performance counter to reach over
300K connections (!), enough to start worrying...
My crawler is designed to support around 200 connections simultaneous.
"netstat -an" doesn't support this finding, but does show hundreds of
connections that are in either "CLOSE_WAIT", "FIN_WAIT_2" or another
closing state.
After a host has completed, I try to disconnect the TCP/IP connection.
I've attempted combinations of "shutdown(both)", (async) "disconnect"
and "close(0)" - where no combination appears to have the desired
effect. When the application is shut down, all connections (including
the CLOSE_WAIT connections) are removed. The FIN_WAIT_2 connections
linger forever...
Perhaps someone knows a solution to this problem?
Greetings,
Stefan de Bruijn.- Hide quoted text -
- Show quoted text -

I couldn't reproduce it, but I can only do it at home as I've only got
access to 1.1 in the office and the Socket implementation is
different. Can you reproduce it in a tiny bit of code, ie just create
a socket, set the options, connect to a URL retrieve a bit of data and
close it? That's what I tried last night. I even tried things like not
closing the socket and so forth and couldn't get a FIN_WAIT_2.
Interesting problem though, networking in general is fascinating imo.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

 

[atlaste]

I can currently say for sure that this solved the problem. Setting the
"blocking" property to "true" before calling shutdown and close was
indeed the solution.

I'd say this is a bug in the .NET framework - one that most people
will never run into fortunately. You could argue that blocking affects
the behaviour in favor of not calling it a bug, but even if blocking
affects the behaviour, the socket is still disposable and hence should
have been cleaned up.

Thanks for thinking along, DeveloperX.

Greets,
Stefan de Bruijn.

Yes!

The "blocking = true" in the disconnect phase seems to solve the
problem. Oddly enough.

So I took Lutz' reflector and started browsing through the code ofSocketand TcpClient (which I don't use), till I found some strange
things. First there's the code of System.Net.Socket.Dispose(bool)
(called from Close(int)). Once the dispose process is starting, the
"disposing" part of this method starts to kick in, trying to force a
blocking connection somewhere down the line. To be honest I can't find
a reason why this done, but I'm sure it's there for a reason. Funny
enough I set the close timeout to 0, so that particular line of code
is never hit (and if it was, then I'm quite confident the winsock2 api
will return a 'disconnected' error due to the shutdown).

The second thing I noticed is that the cleanup procedure for 0 timeout
and the procedure for non-0 timeout is quite different. In this case
it would mean 'shudown' is required for a Close(0), but not for a
Close(1). I can see now why the shutdown is a good idea for proper
programming.

Another difference I've spotted is in the closing in TcpClient andSocket. The former calls "InternalShutdown", while the latter calls
"Shutdown". The latter is the call to shutdown which we (normal users)
use onsocketas well to close both ends of the connection (i.e.
mysocket.Shutdown(SocketShutdown.Both). So I grabbed the
documentation of shutdown:http://msdn2.microsoft.com/en-us/library/ms740481.aspx
- which explicitly states a call to "closesocket" should be placed -
which in turn is responsive to blocking mode.

Funny enough I can't find a call to 'closesocket' anywhere... strange
isn't it?

Anyways, I'm 50% confident that this problem is solved. The other 50%
concerns about the closesocket call. Furthermore I wonder if this is a
MS bug or desired behaviour. And while wondering I strongly feel that
it would be very nice if someone would be kind enough to create a
couple of small examples (blocking, non-blocking, polling) of propersocketprogramming.

Cheers,
Stefan de Bruijn.

Lazy as I am, I haven't created a minimal testcase. Okay, that's not
really true... I just don't know how to create one, since I'm doing
terrible things with the sockets api, that I don't really know how to
reproduce in a proper context (read: without getting angry faces).

I did attempt to useasyncmethods ofsocket, like Peter suggested.
Furthermore I keep track of TCP connect and disconnect operations in a
performance counter just to make sure no resource is
"leaking" (although that shouldn't be a problem in a GC'ed language
you could but shouldn't think...).

Funny enough the approach did help me somewhat. That said, I have to
elaborate on that:

I nowadays rely on the begin/end methods of connect and send. For the
disconnect operation I use the following sequence:

socket.LingerState = new LingerOption(true, 0);
socket.Shutdown(SocketShutdown.Both);
socket.Close(0);

Seehttp://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.li...
for an explanation of the lingerstate I set during the way.

The usual behaviour is that *any* TCPsocketoperation on the pc just
fries. So it looks like the resources are slowly drained. The program
actually seems to work for a random amount of time; which supports the
theory, since not every host needs the same processing. I went back to
my log files and tried to find a pattern that matches the behaviour of
the program. It seems that the behaviour is not really random (!), but
rather magically has something to do with a factor (of connected/
disconnected) close to 61000.

... why does that remind me of 2^16, which is usually the number of
file descriptors?

I currently try setting thesocketback to blocking mode before
setting the lingerstate because I want to avoid that setting to affect
thesocketbehaviour (although it shouldn't). I should have the
results in about .. 4 hours or so... I hope this will end my long
journey of creating a "simple" TCP/IP client.

Cheers,
Stefan de Bruijn.

Well actually I have tried theasyncmethods of webrequest, libcurl,
libwww and some other solutions. I am well aware of the capabilities
of those implementations.
Perhaps not so needless to say is that I don't merely concentrate my
efforts on http/web, but also on other protocols (which aren't so well
supported). I chose the example of a webcrawler because it is in my
opinion a good example of the amount of distribution and connections
that I'm looking for. Furthermore I'd like to compare the different
methods to evaluate them and simply pick the best method for my
purposes.
Reinventing the wheel or not and discussing if I'm doing that or not
isn't really what I would like to debate. The fact remains that the
whole network traffic just shuts down with my tcp wrapper class, which
just shouldn't happen in any case.
Thanks,
Stefan.
On Mar 28, 3:13 am, Peter Bromberg [C# MVP]
Stefan,
I don't understand why the effort to (in some ways) "reinvent the wheel",
but I've written what I believe are very efficient webcrawlers using the
built-in asynchronous methods without any of the nasty side effects you
describe. Timeouts can be added if necessary.
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
:
Hi,
In an attempt to create a full-blown webcrawler I've found myself
writing a wrapper around theSocketclass in an attempt to make it
completelyasync, supporting timeouts and some scheduling mechanisms.
I use a non-blocking approach for this, using the call to 'poll' to
support theasyncmechanism - rather than the 'begin' and 'end'
functions. I already found that connecting doesn't set the
"isconnected" variable correctly (SocketException is thrown: non-
blocking has this effect...) - but doesn't appear to be a problem
because poll, read and write work fine.
For measuring the performance of the crawler, I started "perfmon.msc"
and added the "active connections" item from object "TCP". After a
while I found the number of this performance counter to reach over
300K connections (!), enough to start worrying...
My crawler is designed to support around 200 connections simultaneous.
"netstat -an" doesn't support this finding, but does show hundreds of
connections that are in either "CLOSE_WAIT", "FIN_WAIT_2" or another
closing state.
After a host has completed, I try to disconnect the TCP/IP connection.
I've attempted combinations of "shutdown(both)", (async) "disconnect"
and "close(0)" - where no combination appears to have the desired
effect. When the application is shut down, all connections (including
the CLOSE_WAIT connections) are removed. The FIN_WAIT_2 connections
linger forever...
Perhaps someone knows a solution to this problem?
Greetings,
Stefan de Bruijn.- Hide quoted text -
- Show quoted text -
I couldn't reproduce it, but I can only do it at home as I've only got
access to 1.1 in the office and theSocketimplementation is
different. Can you reproduce it in a tiny bit of code, ie just create
asocket, set the options, connect to a URL retrieve a bit of data and
close it? That's what I tried last night. I even tried things like not
closing thesocketand so forth and couldn't get a FIN_WAIT_2.
Interesting problem though, networking in general is fascinating imo.- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -