| Marshall Brooke |
I have a client and server which communicate via ascynchronous sockets.
If I am sending a large file from the client to the server and I just
kill the client app during mid transfer (either by closing the form or
just killing the process) the server then kicks up an untrappable error
in "System.Net.Sockets.OverlappedAsyncResult.CompletionPortCallback".
This error cannot be caught by try..catch and means that you cannot
clean up properly in the event of a catastrophic failure. I have to
spawn another Timer Thread and periodically check each sockt state
object to see wether it has completed in a specific time period or not.
There is no way that I can guarantee that all clients will properly
close their sockets. If a client suddenly closes the socket for some
reason in mid transfer, then all works OK. I have seen a few reports of
this bug on the web but not much feedback.
best
Marshall
|
|
| |
| |
| Bob |
You might want to post some sample code to
convince people showing the problem, or they
might think your code is buggy...
(Given that I've been involved in projects
running similar scenarios with high load
over several servers with multiple connected
clients and never seen this happen, I find
it more likely that the bug is in your code,
but of course I may be wrong...)
"Marshall Brooke" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
| |
| |
| Marshall Brooke |
Thanks Bob,
I have attached the main Client and Server files. So the client will
send the file asynchronously and the server will receive the file
asycnhronously. All works perfectly with multiple clients etc. However,
if you are transfering a large file and suddenly kill the client app,
you then get the nasty error on the server and you cannot clear up
cleanly. If you have some client/server code where both are
communicating asynchronously and you have no such problems if you
suddenly kill the client app in mid transfer without cleaning up the
sockets, I wonder if you could let me know what I am doing wrong. As I
say, this code works perfectly if you allow the client to complete its
upload, or if you Cancel the upload, thus giving the client the chance
to close it's socket cleanly. I also see this error in some async Web
Services. All works OK, and then suddenly the client app will pop up
with the the same error. It seems as though there is a cross thread
issue in the .NET core which cannot handle async errors cleanly and
marshal the error back to the calling thread.
I am using .NET 1.1 on Windows 2003 Server
best
Marshall
|
|
| |
| |
| Feroze [MSFT] (VIP) |
Hi!
Can you give us some details about your application ? What kind of hardware
are you running the client & server on ? Is it a Single/Multiproc
environment ?
ALso are you going localhost only, or over the network ?
We are unable to reproduce the behavior you are describing with your code.
feroze.
--
Remove "user" from the email address to reply to the author.
This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Marshall Brooke" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
----------------------------------------------------------------------------
----
[Original message clipped]
oolean.TrueString);
[Original message clipped]
char[] {':'});
[Original message clipped]
None,new AsyncCallback(this.EndReceive),state);
[Original message clipped]
lit(new char[] {':'});
[Original message clipped]
----------------------------------------------------------------------------
----
[Original message clipped]
nnection"];
> public static System.Threading.ManualResetEvent Accepted=new
ManualResetEvent(true);
[Original message clipped]
on);
[Original message clipped]
..Stream,ProtocolType.Tcp,options);
> _server=new
Socket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);
[Original message clipped]
e,new AsyncCallback(this.EndReceive),state);
[Original message clipped]
..Message)));
[Original message clipped]
tion"]);
[Original message clipped]
|
|
| |
| |
| Marshall Brooke |
Feroze [MSFT] wrote:
[Original message clipped]
This was my fault, I had a BeginSend and a BeginRecieve at the same time
on my client app. This is what caused the error on the server. I
basically started a BeginReceive call on the client so that I could
receive any event notifications from the server. I guess this flies in
the face of propert client/server TCP communication where everything
must transmitted in order. Hey ho, at least I've learnt something.
Thanks
Marshall
|
|
| |
|
| |
| Marshall Brooke |
Feroze [MSFT] wrote:
[Original message clipped]
Scrap my last post, I still do have a problem. I have attached some
very simple and crude code that demonstrates what I am experiencing, is
there anything wrong as far as you can see?
Here is the scenario
1. The server waits for connections
2. The client connects
3. The server asynchronously waits for data
4. The client asynchronously sends data
5. When the client has sent all his data, he asynchronously waits for
a response from the server
At this point, if I kill the client app (either close the form or kill
the process), I get the error on the server. This happens both on
localhost and when the client is a foreign machine. It basically seems
to be a problem when a socket is not shutdown properly. I have run it
both on Windows 2000 and Windows 2003 single proc machines. Both
machines run v 1.1 of the Framework and are all patched up to date.
best
Marshall
|
|
| |
| |
| Marshall Brooke |
Marshall Brooke wrote:
[Original message clipped]
I've just tried this code on another Windows 2000 server and the error
message is now the correct one .ie "Connection Forceably closed by
remoste host". I think I may have found a name for my pain and it is
Cisco VPN software. My Windows 2003 server and another windows 2000
workstation both have VPN software on and they throw up a really nasty
error with exactly the same code. Must be some low level networking
issue - thanks Cisco.
best
Marshall
|
|
| |
| |
| Feroze [MSFT] (VIP) |
Are you sure that this is an infrastructure issue ?
--
Remove "user" from the email address to reply to the author.
This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Marshall Brooke" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
| |
| |
| Marshall Brooke |
Feroze [MSFT] wrote:
[Original message clipped]
with an Internet monitoring module that comes with my antivirus software
which is Nod32 www.nod32.com. This module exists, I thought to protect
all pop3 mail coming into my system (nice idea and works well).
However, it appears that it makes hooks into all socket level activity
on the system. Everything seems to work OK in .NET land UNLESS a
connection is terminated without closing the socket down first. In this
case, the socket error from winsock does not seem to traverse through
the nod32 module and back into .NET land in a nice way at all, and the
nasty Overlapped socket error occurs. If I just shut down this module,
then everything works OK again. I don't know if this is a problem with
the antivirus software not playing nicely with the OS, or if .NET is not
coping with the error correctly. I have spoken to nod32 support, but
the problem is at such a low level, that it needs to go further up their
development chain.
You may recall that I have placed a number of related posts on this
issue, some to your Blog. The other big one was that when a persisted
HTTP 1.1 connection is closed by the server, the .NET client side code
can no longer call the server. All these problems relate to the same
problem with Nod32 and exist down at the socket level.
So, there is a problem somewhere, but at least I understand it now.
Nod32 Internet monitoring services have officially been made redundant
on my system!!
best
Marshall
|
|
| |
| |
| anonymous@devdex.com |
I'm experiencing th same problem with the
System.Net.Sockets.OverlappedAsyncResult.CompletionPortCallback error.
I have a .net web service on a Win2000 server. Intermittently it will
just "stop" receiving requests. I've can get this to happen on my local
host (Win2000 Pro), running in the .Net IDE. The IDE catches the error,
when none on my Try/Catch statements catch it.
The problem happens after, not during web service transaction. I run a
test of a local consumer to my local web service (in IDE)...wait several
minutes, then receive the message box with the error.
When a problem happens on the Web Server running the service, again
after the transaction has processed, the service appears to stop. When
I look at the task list I see aspnet_wp running at almost 100% on the
server. I kill this process, and the service again begins responding to
requests.
Admittedly, these could be 2 different problems. But since the both
happen outside of a consumer to service call, they appear somewhat
similar to me.
Any ideas or thoughts?
BTW: I'm using McAfee Virus software on both local and server pc.
Thanks,
Bob
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
|
|
| |
| |
| Richard |
Hi all!
I'm using remoting CAO's and singletons and getting a
System.Net.Sockets.OverlappedAsyncResult.CompletionPortCallback exeption
on the server Whenever a client is closed down.
I'm fairly new to remoting and .net in general and was wondering if I am
closing the client app in the correct manner. All examples I've seen do
not specify methods of closing down the client and seem to just allow
the remote objects to expire, is this correct?
I am also usig McAfee Firewall and antivirus but the problem persists
even if they are diasbeled.
Also the the OverlappedAsyncResult part is cofusing as I am not using
asyncronous method calls.
I'm pretty sure this is a problem with my code and not an unresolvable
issue as described above any sugesstions on where how to resolve this
would be appreciated or even a shove on the right direction would be
helpful.
The client and server are both running on localhost, the remoting server
does make use of a web service to retrieve some data but I'm 80% this is
unrelated as the all works fine while the remoting client is running.
I'm using Windows XP professional and the Server offers two SAO
singlecall, one singleton and one CAO is there an proper method of
disconnecting from remoting objects?
Also the problem only occurs about 80% of the time.
Thankyou Richard!
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
|
|
| |
|
| |
| Richard hartzenberg |
Hi all!
I'm buildig a remoting client server application that uses a CAO and a
singleton object.
I'm getting the same type of
OverlappedAsyncResult.CompletionPortCallback exceptions on the server
whenever a client is closed down. I am fairly new to .net and remoting
amd am unsure if I am disconnecting form the remote objects corrrectly,
I am not using asynchronous calls and assumed fromall examples I've seen
that in this case objects can just be allowed to expire when client
closes.
I am also using McAfee firewall and viruscan but the problem persists
even when they are disbled.
Any suggestions on resolving this would be appreciated or even pointers
in the right direction.
The problem is possibly due to inexperience on my part but is confusing
as only occurs about 80% of the time.
Thanks Richard
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
|
|
| |
| |
| Marshall Brooke |
Richard,
I had exactly the same issue. I gurantee you 100% it is to do with any
firewall/internet monitoring software on your machine. I was running
Nod32 antivirus which has an internet module that monitors primarily the
pop3 port. As soon as I disabled this everything worked perfectly.
With McAfee, you may need to uninstall that module completely if the
problem still persists when you disable it. I do not know if this is a
situation of .NET incorrectly handling any socket abnormalities, or if
it is a case of evil antivirus software. I think that .NET should be
able to trap any socket problems and fail gracefully. The
OverlappedAsyncResult error in my View should translate to the error you
get when a socket is closed down in normal circumstances. This is a
huge issue with .NET when you think about it, but it doesn't seem to be
that widespread. .NET needs to be black boxed against such issues. You
will find that any socket based apps will fail with this error. The
short of it is, you cannot have your current antivirus system with all
its settings and .NET working in harmony. So far then McAfee and Nod32
are both problematic with .NET.
Marshall Brooke
|
|
| |
| | |
|
|
|
|
|
|
|
|
|
|
| | |
|
