On Tue, 20 May 2008 11:02:53 -0700, Ryan Liu <rl**@powercati .comwrote:
[...]
I frequently see the error on server side(client side code is same, but I
don't see the error):
"System.IO.IOEx ception: Unable to read data from the transport
connection:A
blocking operation was interrupted by a call to WSACancelBlocki ngCall"
You shouldn't have code using WSACancelBlocki ngCall. Without a
concise-but-complete code sample that can reliably reproduce that error,
it's not really possible to say how it is you do have code using that
function.
This error msg is seen when sever thread endless read from network
stream.
What does this mean? Can I solve this problem by using async I/O on
server
side?
Does client using which type I/O affect server side?
Well, using async i/o will avoid using blocking calls, which in theory
should prevent a blocking operation from being interrupted by
WSACancelBlocki ngCall. But since the function shouldn't be getting called
in the first place, it's not clear that's the right solution. It would be
better to find out why your network i/o code is being affected by
functions that should theoretically not be part of your code at all.
When server thread writes to the network steam, there are also error
soemtime: "System.Invalid OperationExcept ion: The operation is not
allowed on
non-connected sockets. "
How can I avoid sockets getting disconnected? Is this also due to
"interrupte d by a call to WSACancelBlocki ngCall" error when read from
socket?
Without code, it's hard to say. It's certainly possible that whatever is
causing the problem is also disconnecting your socket. But a socket can
always wind up disconnected for a variety of reasons. While the question
of WSACancelBlocki ngCall is still in need of pursuing, your code should
always be able to deal with a disconnected socket.
-------
One time I used async I/O on sever side and sync I/O on client side, then
the server shuted itself down automatically, later I found there are
Trojan
Horse virus in the network. I don't know the server crashs due to my new
code or because of virus . I don't always have the chance to try out my
new
code.
Malware certainly has the potential to cause problems like this, depending
on how virulent it is. Malware can introduce all sorts of new
complexities and errors.
Is this your problem? Hard to say without more specifics. If you can
reproduce the problem on a known clean system, then I'd say it's not. If
the problem only ever shows up on a specific computer, then I'd say it
very well could be malware.
That time I also see async new read error on server side when
NetworkStream.E ndRead(), but seems it is more reasonable, and I just
ignore
and BeginRead again:
With most errors, you need to simply close the socket and start over.
Very few errors are recoverable, and those that are, are specifically
documented as being recoverable and in fact are more informational than
being actual errors (for example WSAEWOULDBLOCK) .
" System.IO.IOExc eption: Unable to read data from the transport
connection:
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond. --->
Sounds like some sort of timeout. However, you said you're using
synchronous i/o, so I don't know why the stack trace would show only calls
to the async i/o methods.
Generally speaking, unless you've messed with the timeout properties on a
socket or have set keep-alive on the connection, only connection attempts
will timeout. Sends and receives will simply block until interrupted (by
closing the socket) or being completed. If you've done something that
enables timeout behavior on the socket then, well...yes, it could timeout.
Again, without code, it's not possible to say what's actually happening.
[...]
"System.IO.IOEx ception: Unable to read data from the transport
connection:
An existing connection was forcibly closed by the remote host. --->
System.Net.Sock ets.SocketExcep tion: An existing connection was forcibly
closed by the remote host" -- Is that true? But I didn't write any code
on
client side to close the connection until logout.
"Forcibly terminated" is a way of saying that the connection was reset
ungracefully. This almost always happens _outside_ your code, since
normally people write network code that only closes connections
gracefully. As for why the connection got reset, it's hard to say. It
can happen for a variety of reasons, including a network cable being
disconnected (if the Windows "media detect" setting is enabled) or some
malicious third party somewhere along the line of transmission (for
example, Comcast has been caught forging connection reset packets, causing
TCP connections to be dropped arbitrarily).
What all these mean? What makes it so fragile? Where to get started to
learn
write more roburst network program?
Well, networking is kind of fragile. It relies on a lot of intermediate
components outside your control and your own code needs to anticipate the
kinds of things that can occur.
As for where to start, I'm not really sure. I'm not an expert, and what I
do know I mostly learned "the hard way". :) But one useful place to start
is reading the Winsock FAQ:
http://tangentsoft.net/wskfaq/ It's not what
I'd call an exhaustive reference, but it certainly covers most of the most
common issues people new to network programming might need to learn, or
might run into. Winsock isn't the .NET API per se, but it's what the .NET
API is built on, and the socket API defined by Winsock and BSD sockets
(from which Winsock was initially derived) forms the basis for the most
common network APIs you'll run into.
Pete
