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

  • 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. – devuxer Jun 30 '09 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. –  Jun 30 '09 at 20:04
  • possible duplicate of [Official reasons for "Software caused connection abort: socket write error"](http://stackoverflow.com/questions/2126607/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. – user207421 Sep 18 '12 at 06:11

7 Answers7

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

Community
  • 1
  • 1
zahical
  • 246
  • 3
  • 8
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.

  • 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 http://www.chilkatsoft.com/p/p_299.asp to understand it better. – Aditya Sehgal Jul 01 '09 at 05:06
  • 1
    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. – user207421 Sep 18 '12 at 06:11
1

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

ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • 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. – muusbolla Jun 30 '09 at 21:04
  • 1
    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). – ChrisW Jun 30 '09 at 22:27
  • 1
    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. – Aditya Sehgal Jul 01 '09 at 05:00
1

To forcibly abort a connection you can do:

socket.Close(timeout: 0)

This will send a RST immediately.

Miles
  • 488
  • 5
  • 19
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.

HasaniH
  • 8,232
  • 6
  • 41
  • 59
-1

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

Kostas Konstantinidis
  • 13,347
  • 10
  • 48
  • 61
-1

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

Jorge Mota
  • 50
  • 1
  • 5