Hi Joel
I updated to 1.3.0.1 version this time but
Every time call send method,
ClientDisconnedted event occurs.
It didn't occur in previous version(1.2.1.2)

os: windows 10 pro (64bit)
framework: .net core 3.1

Hello. After three days of unsuccessful struggle with the problem, I decided to write to you.
I would be very grateful if you can help me ...

I am using your library to connect to a board I developed based on STM32 controller. I used to start with NET CORE 3.1 and your library worked just like a charm. However, after switching to FRAMEWORK 4.8 in standby mode, the receiving buffer is filled with some periodicity with 0x80 trash bytes.

In the picture I am sending 2 bytes for a request and should receive 20 bytes as a response from the server.
The source code of the two applications is identical and does not differ by a single character.
The same problem is observed in your other library - SimpleTcp.

Can you somehow help me with this problem?
Thank you in advance...

Operating system and version: Windows 10 x64, .NET Framework 4.7.2.
Issue encountered: Memory leak.
Expected behavior: CancellationTokenSource objects are disposed.

Hi. I've been using HttpServerLite and found a memory leak inside related CavemanTcp library during my investigation. There is also a place without proper resources disposal in HttpServerLite, but it's pretty minor (_TokenSource is canceled but not disposed in Dispose method of Webserver.cs). That memory leak is caused by creating CancellationTokenSource and leaving them hanging in memory. Therefore the more requests incoming, the more detached CancellationTokenSource objects are piling in the second Heap generation.

This leaking CancellationTokenSource issue relevant for the next methods inside CavemanTcpServer.cs:

• AcceptConnections() [my main concern]
• SendWithTimeoutInternal(...)
• SendWithTimeoutInternalAsync(...)
• ReadWithTimeoutInternal(...)
• ReadWithTimeoutInternalAsync(...)

Also, in synchronous Start() method there is double _TokenSource assignment that lead us to one detached CancellationTokenSource.

As possible solution for CancellationTokenSource disposal in AcceptConnections(), i can suggest the next code that helped me in my tests.

var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(_Token, client.Token);
var _ = HandleClientConnection(client, linkedCts.Token)
        .ContinueWith(x => linkedCts.Dispose())
        .ConfigureAwait(false);

In case of other unhandled places we can use for example using or try{}finally{}.
To prove CancellationTokenSource memory leak there is a screenshots from dotMemory profiler with fixes and without + list of alive objects where CancellationTokenSource at the top with extremely high number of retained bytes.

I'm having issue disconnecting clients from a server. The server can disconnect them just fine, but when I call Disconnect() on the client, it never returns. Same with the Dispose(), which seems to be basically equivalent.

Edit: I have created a very basic server / client app with CavemanTcp and there the Disconnect on Client works. But I'm still unable to fix my issue in my actual code. From looking at the Dispose method in you code, I'm unable to think of a reason it would not return. Any help would be appreciated.

I'm really out of my wits with this. I'm creating an app to send data between computers, I've already raised an issue here a while back.
In essence, the connection is randomly terminated. Mid Send and Read on client and server respectively. I have made sure I am not calling any disconnect method on either. The WriteResult just returns as Disconnected at a random point during the process. I have considered Keepalives to be the cause and once disabled, it worked once, but I then reenabled and when I disabled again, it no longer worked. I am now at the state, where I send the same data over and over and there is seemingly a random % chance of the client or server disconnecting during the data transfer (unsure as to which one causes it). So I do not believe the Keepalives to be the cause of the problem, but they now are disabled on both.

The problem is on this branch of my app. The problem is centralized to the TransferClient and its SendFile function, which does the actual file data transfer. There, there is result = client.Send(buffer); and this result sometimes equals WriteResultStatus.Disconnected, because the client disconnects.
For reference, this is my server class .

Once again, I'm not calling for any disconnects myself. I have even completely disabled my disconnecting method TerminateConnection and it still happens.

Would appreciate any help, as this is a bit urgent and I really can't find anything else to try. I was sure it must be a bug in my code, but I have tried everything I could think off and it really doesn't seem like it, so maybe the Keepalives are enabled even with Keepalive.EnableTcpKeepAlives = false?

I should add that Keepalives shouldn't even have time to fail, as they were set to the default 5,5,5 for the values before I disabled them, and the error happens within the first 1-2 seconds of the connection, usually less. But I have also tested the Keepalives to detect a ethernet cable disconnect practically immediately, so I'm not sure how they work exactly.
Also from my test it seems that the client disconnects from the server, not the other way around, as the client's Events_ClientDisconnected seems to be called earlier then the server's.

Hello,

When using TcpServer my client connections were keep closing, after I dig a bit found out that IsClientConnected method returns false even when client is still connected. I don't know why but at

if (!client.Connected) return false;

client.Connected returns false but client is still connected. Even I can send an receive data.

After searching a bit found out that client.Connected is not that reliable. At StackOverflow found out this code and looks like it's working ok.

public static TcpState GetState(this TcpClient tcpClient)
{
    var foo = IPGlobalProperties.GetIPGlobalProperties()
                                .GetActiveTcpConnections()
                                .FirstOrDefault(x => x.LocalEndPoint.Equals(tcpClient.Client.LocalEndPoint)
                                                     && x.RemoteEndPoint.Equals(tcpClient.Client.RemoteEndPoint));

    return foo != null ? foo.State : TcpState.Unknown;
}

Hello again friend!

After a few years I have returned again to your wonderful suite of TCP libraries. This time more armed with knowledge than before!

So I have read numerous articles off-and-on about the performance-woes of TCP... and about how UDP comes with its own connectivity/firewall woes.

I found an book article proposing parallel TCP connections where each connection has only one single in-flight message at any given moment. The mechanism increases overall connection reliability and consistent improved latency. It can even be used with websockets, which is slick.
Here it is:
http://ithare.com/almost-zero-additional-latency-udp-over-tcp/

Building upon that, when a person begins to scrutinize all of the metrics for deliverability, the issue of max MTU sizing also comes up. If you send a TCP packet that exceeds an MTU size, it can cause problems. So what you end up wanting in a perfect world (where latency and reliability is prized foremost) is:

• Application takes responsibility for framing its data into small enough messages that one message can be sent in one packet and is guaranteed not to be auto-fragmented in-flight by a network device.

• Application can then guarantee when it performs a network send, the data is received all-or-nothing with maximum deliverability, and the application can continue to send other packets on parallel connections if it chooses to do so.

So I went back to looking at off-the-shelf TCP tooling and it looks like Caveman gets the closest to allowing some kind of implementation like this without having to go to bare .NET BCL tooling.

I wonder what are your thoughts on an implementation that accomplishes the objectives above?