Re: Async socket & active connections
- From: "atlaste" <atlaste@xxxxxxxxx>
- Date: 3 Apr 2007 13:56:52 -0700
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.
On 3 apr, 09:29, "atlaste" <atla...@xxxxxxxxx> wrote:
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.
On Apr 2, 7:29 pm, "atlaste" <atla...@xxxxxxxxx> wrote:
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.
On 30 mrt, 11:38, "DeveloperX" <nntp...@xxxxxxxxxxxxx> wrote:
On 28 Mar, 12:58, "atlaste" <atla...@xxxxxxxxx> wrote:
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]
<pbromb...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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
"atlaste" wrote:
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 -
.
- References:
- Re: Async socket & active connections
- From: atlaste
- Re: Async socket & active connections
- From: atlaste
- Re: Async socket & active connections
- Prev by Date: Re: XML parsing: no EndElement for combined start/end tags
- Next by Date: Creating controls dynamically
- Previous by thread: Re: Async socket & active connections
- Next by thread: Method Exception information
- Index(es):
Relevant Pages
|
Loading
