search

LiveOrDevTrying / Tcp.NET

Tcp.NET provides an easy-to-use and customizable Tcp Server and Tcp Client. The server is created using a TcpListener. The server and client can be used for non-SSL or SSL connections and authentication (including client and server ssl certification validation) is provided for identifying the clients connected to your server. Both client and server are created in .NET Standard and use async await functionality.
Apache License 2.0
42 stars 10 forks source link

OnConnectionEvent does not fire for client class #1

Closed comanchetr closed 3 years ago

comanchetr commented 4 years ago

Hello, as the title says that event does not fire. However, It fires when the client disconnects. (I'm talking about the client side, it works for the server side)

LiveOrDevTrying commented 4 years ago

Hi comanchertr,

Thank you for the message. I will take a look at this right now - are you using the most recent version of Tcp.NET? Also, are you using Tcp.NET with authorization / authentication and attaching an OAuth token or as your using Tcp.NET for unauthorized connections?

Thanks again and I will post what I find, Rob

comanchetr commented 4 years ago

Hi again, yea I just use the latest github files (I downloaded them 2 days ago). I slightly modified Tcp.Net.TestApps.Client and Tcp.Net.TestApps.Server to measure the performance. I make the server echo server, and in client code I added this code which did not fire( and I eventually I ported it to server side). The code prints client numbers at every 1000 new clients. private static Task OnConnectionEvent(object sender, TcpConnectionClientEventArgs args) { switch(args.ConnectionEventType) { case ConnectionEventType.Connected: _temp++; if(_temp % 1000 == 0) Console.WriteLine(_temp); break; case ConnectionEventType.Disconnect: break; case ConnectionEventType.Connecting: break; default: break; } return Task.CompletedTask; } Then I tried this and it fired only when disconnecting. I concluded that only disconnecting fires this event.

private static Task OnConnectionEvent(object sender, TcpConnectionClientEventArgs args) { _temp++; if(_temp % 1000 == 0) Console.WriteLine(_temp); return Task.CompletedTask; }

Rest of the codes are almost same. I create a byte[32000], I convert it to string and send it for each client and reply with the same message in server (btw 15000 clients I expected but connection slows down when nearing 10K clients which is still good indeed but..)

LiveOrDevTrying commented 4 years ago

Hello again,

Let me take a look at the Client side code today - there is probably a problem with when the connection event fires and / or something related to the async await. The Connected event should only fire after the auth message is successfully received, which more than likely is the problem.

15000 clients sounds excellent, I can understand the slowdown at 10k clients. Tcp.NET manages auth in addition to connections, and it is using TcpServer and TcpClient classes instead of the Socket lower-level object. If you are expecting that much load, I recommend using n-tier architecture and horizontally scaling your app and using something like Redis or Elasticache as a middle layer to sync the instances. Then you could have another Tcp Server dedicated to authorization, and the application TcpServers will be operating at full capacity. I will look at the Client now and post an update with what I found.

Thanks again and I will post back shortly, Rob

comanchetr commented 4 years ago

Ok, thank you very much for your recommendations and attention. I'm just evaluating libraries to get a grasp of general performance of .net networking classes. EAP sockets are very fast but they have weird crashes under high bandwidth usage, reporting wrong receive size in multiple libraries for instance. I think TcpListener/TcpClient more robust. I will probably have 10 users at most for my in house application. I will be keep looking and close the topic when the problem is solved by the way. Your library and work are much appreciated. Thanks.

LiveOrDevTrying commented 4 years ago

Ho @comanchetr,

Apologies on the delay. I have pushed v 1.4.5 of Tcp.NET up this morning, and the event for client connection event has been resolved. The problem was the event was not ever coded in. :X Should be fixed now, give it a test and let me know. I also updated the documentation.

Thanks again, Rob