9

I'm trying to abort a socket connection such that the client at the other end will get a "WSAECONNABORTED (10053) Software caused connection abort." error message when it polls the connection.

Close() and Shutdown() will disconnect gracefully. I don't want a graceful disconnection. I want to do an Abort so that the client senses something really went wrong.

Thanks,

EDIT: I'm coding a Server and I want to abort sockets to connecting clients

Improve this question
3
  • I'm not sure how to do what your asking, but it seems like the client would have expectations about what it will be getting via the socket connection. If the server passes a value that doesn't make sense to the client then gracefully shuts down, wouldn't that have the same effect as aborting the socket? For example, client expects int value, server sends string then closes. Just a thought. Commented Jun 30, 2009 at 19:45
  • I'm coding a server and I want the server to Abort the connection if the client sends data that does not meet the protocol's specs. Commented Jun 30, 2009 at 20:04
  • possible duplicate of Official reasons for "Software caused connection abort: socket write error". That being so, you can't simulate it, as it comes from the TCP stack under network failure conditions. Commented Sep 18, 2012 at 6:11

7 Answers 7

Reset to default
5

The underlying details, including when it is actually appropriate to forcibly abort a connection are described in great detail here (https://stackoverflow.com/a/13088864/1280848).

The C# way of doing this is:

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

That is, use SO_LINGER with TIME_WAIT = 0

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

I've managed to simulate this situation:

To do a normal graceful disconnection:

you do:

socket.Shutdown(SocketShutdown.Both); socket.Close();

However, to do an Abort, you do:

socket.Shutdown(SocketShutdown.Send); socket.Close();

I think the difference is that the client will not receive any ACK packets and thinks the computer reset or something.

Improve this answer

2 Comments

TCP is a bi-directional protocol i.e. it requires closing of connection from both sides. So, when you call Shutdown with "SocketShutdown.Both", it disables both Sending and receiving on the socket. However, when you do "SocketShutdown.Send", the Server closes its side of the TCP connection. In this scenario, when the client tries to send messages to server will receive ECONNABORTED. Take a look at chilkatsoft.com/p/p_299.asp to understand it better.
This does not cause a connection abort of any kind, let alone the one in the OP's question. Shutting down for send just sends the FIN prematurely, but it would have been sent by the close anyway. There is normally no need to shutdown immediately before close at all. There is a way to force a connection reset but I'm not going to document it here as there are vanishingly few correct uses of it.
2

To forcibly abort a connection you can do:

socket.Close(timeout: 0)

This will send a RST immediately.

Improve this answer

1 Comment

This indeed sends a connection reset. Thanks!
1

What if you kill the process, and/or reboot the machine, and/or unplug the ethernet cable, without calling Close() and/or Shutdown()?

Improve this answer

3 Comments

are you joking? clearly he wants the program to send ECONNABORTED when an error occurs. requiring that he physically crash the network link/process completely defeats the purpose.
I meant, kill the other process at the other end of the connection. He wants this program to receive ECONNABORTED from its local TCP stack, which (I think) happens if the connection is abended (e.g. if the remote peer disappears).
I agree with Chris. You cannot have the Server sending ECONNABORTED. Only when the client will see missed Acks for the data it sends will it receive ECONNABORTED on the next Send call.
0

I don't think that it is possible to get the behavior you want with the .Net Socket implementation other than having the client send intermittent keep-alives. I've tried all sorts of things to get the behavior you described and ended up implementing keep-alive messages. If the sever calls Close() the client socket will get a connection aborted error the next time it attempts to send data.

Improve this answer

Comments

-1

try calling EndSend() or EndReceive() depending on the situation immediately followed by a Dispose()

Improve this answer

Comments

-1

you can try to code all secondary sockets in another thread, and kill it when you want to crash connections.

Improve this answer

1 Comment

However it will not have the desired effect. Please don't post mere guesswork here.