Netly version 4 changelog. #36
Pinned
alec1o
announced in
Announcements
Replies: 1 comment 4 replies
-
waiting 😊 |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Netly version
4
ChangelogOverview
Features
New
New
New
New
New
New
New
(e.g HTTP Callback type per request: Task, ThreadPool, Thread)Upgrade
Updates
Performance
Performance
Performance
Performance
Netly.Core
namespace >>Netly
Netly.Core.MainThread
class >>Netly.Ny.MainThread
Description
Syntax
Netly syntax was updated... Code below!
HTTP
Server (HTTP & WebSocket)
RUDP
Namespace Update
Warning
HTTP.Server
new
HTTP.Server does not allow listening or binding with SSL/TLS (HTTPS) connection. Because it uses HttpListener as base and HttpListener does not support SSL/TLS (HTTPS). To fix this issue, you must use the load balancer and bind to Netly.HTTP.Server (and it is recommended to use the load balancer in production). Well, after the V4 release, I @alec1o will think if I can ignore this issue or try to fix it. for example, create your own load balancer to mask Netly.HTTP.Server or recreate an HTTP.Server through Netly.TCP.Server to have control and remove HttpListener overhead (hardcore). "I with use only c#, using c++ or external lib isn't on context."
Performance
TCP Performance (+1000%)
With v3, it is possible to handle and remain stable, handling approximately ~300 connections that always send messages to the server. With v4 you can handle and remain stable when handling +20,000 connections that always send messages to the server.
TCP is using Own thread instead of using ThreadPool.
The main difference is that the Thread is managed and processed by the processor and thread pool and is stored in a queue and is executed in the free space of an already existing thread.
[
Click To Read More
]: V3 have bad performance only on server side not in client side, why?v3 uses the thread pool and runs in the free time of an existing thread, which is good for performance-free execution. when using the 0-100 connection it will work very well because there will be time for all these thread pools to be executed, and when you have 1000 pools the system will not have free execution time to execute all the thread pools, so there is an execution queue, This needs a lot of time to run all 1000 pools in free space of the thread, also because the thread pool uses a lot of resources to save and load the execution context. (load, execute, save) the context of 1000 tasks in the thread's free time is very costly and requires execution time that pools do not have, which is why V3 did not support many connections.
In other parts the Thread does not need to save context and is very fast. Thread behaves like threadpool, but it will be handled by the processor and will not need to save and load context, which means it is faster and uses more memory than threadpool.
Beta Was this translation helpful? Give feedback.
All reactions