You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an instance where my server is told to send multiple TCP messages from the main thread on the same clock tick, the lock statement in SendAsync() appears to prevent the second message from sending. However, the method still returns true when the second message fails to send. Spacing out the SendAsync() calls allows the second message to send, but is there a way to determine whether a message actually sends for cases where the lock blocks one? That way, I could just try to send the message until it successfully sends or until I say to stop trying.
I tried doing this with BytesSent, but the value appears to increase even in these cases where the message doesn't actually send. I don't know if this is a bug or me using the method incorrectly.
NetCoreServer.TcpSession
public virtual bool SendAsync(ReadOnlySpan<byte> buffer)
{
if (!IsConnected)
{
return false;
}
if (buffer.IsEmpty)
{
return true;
}
// ----------------------------------------------------------------------------------------
// Prevents second message from sending on same tick. Method still returns true.
// ----------------------------------------------------------------------------------------
lock (_sendLock)
{
if (_sendBufferMain.Size + buffer.Length > OptionSendBufferLimit && OptionSendBufferLimit > 0)
{
SendError(SocketError.NoBufferSpaceAvailable);
return false;
}
_sendBufferMain.Append(buffer);
BytesPending = _sendBufferMain.Size;
if (_sending)
{
return true;
}
_sending = true;
TrySend();
}
return true;
}
The text was updated successfully, but these errors were encountered:
crav12345
changed the title
TcpSession.SendAsync() returns true even if a message fails to send due to lock statement
TcpSession.SendAsync() returns true even if a message fails to send. BytesSent also increases when send fails.
May 13, 2024
Is it possible that this is happening because of the Nagle's Algorithm implementation? As in, the messages are actually sending, but are being bundled by Nagle's Algorithm and being improperly read on my server or client?
In an instance where my server is told to send multiple TCP messages from the main thread on the same clock tick, the lock statement in
SendAsync()
appears to prevent the second message from sending. However, the method still returns true when the second message fails to send. Spacing out theSendAsync()
calls allows the second message to send, but is there a way to determine whether a message actually sends for cases where the lock blocks one? That way, I could just try to send the message until it successfully sends or until I say to stop trying.I tried doing this with
BytesSent
, but the value appears to increase even in these cases where the message doesn't actually send. I don't know if this is a bug or me using the method incorrectly.NetCoreServer.TcpSession
The text was updated successfully, but these errors were encountered: