CODEWITHSUNDEEP
c#socketsasyncsocket
Davita
Davita

Reputation: 9144

Weird behavior of async tcp socket

I have an async server socket listening to some port. Then from another pc, I connect to the server and send 1 byte. Everything works fine, but there's a strange behavior. When I pull of network cable and try to send 1 byte (before os realizes cable was pulled of), I don't get any exception/error and as expected, server don't receive that packet. Is this how sockets are supposed to work? Does this mean that in case of connection loss some packets can be lost (because I don't get an exception and don't know that request was not sent)? Here's the code:

    private void button3_Click(object sender, EventArgs e)
    {
        var b = new byte[1] {1};
        client.BeginSend(b, 0, b.Length, 0, new AsyncCallback(SendCallback), client);
    }

    private void SendCallback(IAsyncResult ar)
    {
        Socket client = (Socket)ar.AsyncState;

        int bytesSent = client.EndSend(ar);

        this.Invoke(new MethodInvoker(() => { MessageBox.Show(bytesSent.ToString() + " bytes sent"); }));
    }

Upvotes: 1

Views: 405

Answers (4)

dvasanth
dvasanth

Reputation: 1377

Windows at socket layer maintains a socket buffer at kernel. A successful send at application layer simply means the data is copied into the kernel buffer. The data in this buffer is pushed by the TCP stack to the remote application. In windows, if a packet is dropped, TCP resends the data for 3 times after which the TCP stack notifies the connection close to the application. Interval between retries is decided by the RTT. First retry is after 1*RTT, second is after 2*RTT & third after 3*RTT. In your case, the 1 byte you send simply copied into the kernel buffer & indicated success. It will take 3*RTT to indicate the socket is closed. This connection close is notified only if you invoke any socket API or monitoring the socket for close event. After pulling the cable, if you queue a second send exactly after 3*RTT, send should through the exception. Another way to get indication of the send failure immediately is by setting the send socket buffer size to zero (SetSocketOption(..,SendBuffer,..)) so that the TCP stack directly use your buffer & indicates a failure immediately.

Upvotes: 1

Warren Dew
Warren Dew

Reputation: 8938

Yes, this is the way TCP sockets are supposed to work. No, this does not mean that the packet is necessarily lost.

What is happening under the covers is this. When you call BeginSend, the byte you are sending is passed to the operating system's TCP stack. The TCP stack then sends the data in a packet.

When the packet is not acknowledged in a reasonable length of time, the TCP stack automatically resends the packet. This happens repeatedly as long as no acknowledgement packet is received.

If you plug the cable back in, one of these resends will get through, and the server will belatedly see the data. This is the desired behavior. Remember that TCP was designed to transmit military data during the cold war; the idea was that even if part of the network got nuked, the routing system would eventually adjust to find another path to the recipient, and the data would eventually get through.

If you don't plug the cable back in, most TCP stacks will eventually give up, terminating the connection. This takes several minutes, however.

More information on TCP retransmission timeout can be found in RFC 1122 here:

https://www.rfc-editor.org/rfc/rfc1122#page-95

Upvotes: 0

quantdev
quantdev

Reputation: 23813

I assume you created a TCP socket.

In that case, your Client will not be notified in case of disconnection (except if your application it sent some kind of logout message).

Looking at the Connected property of the TcpClient :

The Connected property gets the connection state of the Client socket as of the last I/O operation. When it returns false, the Client socket was either never connected, or is no longer connected.

"As of the last I/O" operation : only an (unsuccessful) Read from the Client will help you to detect the disconnection. Many applications implement "pings" to detect some disconnections.

Upvotes: 0

usr
usr

Reputation: 171246

How could the sender possibly tell the packet was not received? It sent it out into a black hole and waits for reply. As long as there is no reply he cannot know whether the packet was received or never will be.

This is usually solved with timeouts. Eventually, the TCP stack will declare the connection dead, or your subsequent reads time out.

Sending does not guarantee delivery at all.

Have the other side send you a confirmation. Your confirmation read will time out eventually.

Or, Shutdown(Send) the socket. This ensures delivery and will throw an exception (after a timeout). You should Shutdown(Both) a socket anyway before closing it to make sure you get notified of all errors.

Upvotes: 2

Related Questions