Question

I have a problem with the SocketAsyncEventArgs class..the problem is when I try to send 8K of data
for example over internet, the socket sometimes only sends 1K or 2K, I know that this is normal for
TCP socket and that one send doesn’t guarantee one receive.
now for this to work for me I modified my code to resend the remaining data, for example
when I the SocketAsyncEventArgs.SendAsync completes, in the callback i check whether it sent all the 8K or not if it’s not, I call the SocketAsyncEventArgs.SendAsync again with the remaining data untill
I send it all.
Now, when I looked at some SocketAsyncEventArgs code.. I saw that most people don’t do so!
and they just clean up when the send complete without checking if it sent all the data or not!
also when I looked at Microsoft’s example, they were saying the ONE call to SocketAsyncEventArgs.SendAsync guarantees that all the data will be sent.
I mean I tested it myself and NO all data will not be sent in one call to SocketAsyncEventArgs.SendAsync.
What I’m doing wrong ?
thanks in advance.

Edit:
Here is the code which doesn’t send all data(exactly like microsoft’s)
the SendAsyncComplete will be called when the socket sends for example 1Kb of data
not all 8K!

public virtual void Send(byte[] packet, int offset, int length)
{
    if (_tcpSock != null && _tcpSock.Connected)
    {
        var args = SocketHelpers.AcquireSocketArg();
        if (args != null)
        {
            args.Completed += SendAsyncComplete;
            args.SetBuffer(packet, offset, length);
            args.UserToken = this;

            var willRaiseEvent = _tcpSock.SendAsync(args);
            if (!willRaiseEvent)
            {
            ProcessSend(args);
            }
            unchecked
            {
                _bytesSent += (uint)length;
            }
            Interlocked.Add(ref _totalBytesSent, length);
        }
        else
        {
            log.Error("Client {0}'s SocketArgs are null", this);
        }
    }
}

private static void ProcessSend(SocketAsyncEventArgs args)
{
      args.Completed -= SendAsyncComplete;
      SocketHelpers.ReleaseSocketArg(args);   
}

private static void SendAsyncComplete(object sender, SocketAsyncEventArgs args)
{
    ProcessSend(args);
}

Answer 1

There are many things I would change there. As a preamble, read this.

First of all, whenever you sent any data on the socket, you must process that event: either you stop the whole send process, or you issue another socket send operation to send the remaining data.

So it makes sense to have 3 methods, like this:

// This is the Send() to be used by your class' clients
1) public void Send(byte[] buffer);

This method will take care to apply any data formatting that you need, create (retrieve) a SocketAsyncEventArgs object, set the token to hold your buffer, and call the next method bellow:

2) private void Send(SocketAsyncEventArgs e);

This one actually calls
Socket.SendAsync(SocketAsyncEventArgs e)
and copies the contents from the token (the buffer, remember?) to the SAEA object. Now that is why because method number (2) might be called several times to send the remaining data that couldn’t be sent in one operation by the socket. So here you copy the remaining data from the token to the SAEA buffer.

3) private void ProcessSent(SocketAsyncEventArgs e);

This last method will examine the data that has been sent by the socket. If all the data has been sent, the SAEA object will be released. If not, method (2) will be called again for the rest of the data. In order to keep track of sent data, you use SAEA.BytesTransferred. You should add this value to a value stored in the custom token I advise you to create (so do not use “this” as a token).

This is where you also check for SocketError on the SAEA parameter.

This last method will be called in two places:

• in the 2nd method, like this:

      // Attempt to send data in an asynchronous fashion
      bool isAsync = this.Socket.SendAsync(e);
  
      // Something went wrong and we didn't send the data async
      if (!isAsync)
          this.ProcessSent(e);
  

This bit is important any many people missed it even when using the more traditional Begin/EndXXX pattern (in that case, via IAsyncResult). If you don’t place it, once in a while (quite rare), a StackOverflow exception will pop out of nowhere and will keep you puzzled for long time.

• in the Completed event handler:

  private void Completed(object sender, SocketAsyncEventArgs e)
  {
      // What type of operation did just completed?
      switch (e.LastOperation)
      {
          case SocketAsyncOperation.Send:
              {
                  ProcessSent(e);
                  break;
              }
      }
  }
  

The tricky thing is to use one SocketAsyncEventArgs object per 1st Send(byte[]) operation, and release it in 3rd operation, if all data has been sent.

For that, you must create a custom token (class or immutable struct) to place in SocketAsyncEventArgs.UserToken inside the 1st method, and then keep track of how much data you have transferred on each Socket.SendAsync() operation.

When you are reading the article provided in the beginning, notice how the writer reuses the same SAEA object when at the end of Send() operation proceeds with a Receive() operation, if all the data has been sent. That is because his protocol is: each one of the parties (server and client) talk to each other in turns.

Now, should multiple calls to the 1st Send() method occur at the same time, there is no rule in which order they will be handled by the OS. If that is likely to happen and message order is important, and since any call to Send(byte[]) from an “outside entity” result in a Socket.SendAsync(), I suggest that the 1st method actually writes down the received bytes in an internal buffer. As long as this buffer is not empty, you keep sending this data internally. Think of it like a producer-consumer scenario, where the “outside entity” is the producer and the internal send op is the consumer. I prefer an optimistic concurrency scenario here.

The documentation on the matter is rather shallow, with the exception of this article, and even in this case, when you start implementing your own application, some things turn out to be different. This SocketAsyncEventArgs model is arguably a bit counter-intuitive.

Let me know if you need more help, I had my times of struggle with this a while ago when I developed my own library.

Edit:

If I were you, I would move

unchecked
{
    _bytesSent += (uint)length;
}
Interlocked.Add(ref _totalBytesSent, length);

to your ProcessSend(SAEA), and use args.BytesTransferred instead of “length”.