Releases · alec1o/Netly

27 Mar 14:42

alec1o

version.4.0.0

bb5a8da

Version 4.0.0 Latest

Latest

Netly version `4` Changelog

_{Hello, I came to inform you that Netly will have a major update and things like syntax changes and more will be described in version 4.x.x. and new features.}

Overview

Features
- Syntax New
- HTTP.Client New
- HTTP.Server New
- HTTP.Websocket New
- RUDP.Client New
- RUDP.Server New
- Ny.ThreadingType New (e.g HTTP Callback type per request: Task, ThreadPool, Thread)
- Byter 4.0 Upgrade
Updates
- TCP.Client Performance
- TCP.Server Performance
- UDP.Client Performance
- UDP.Server Performance
- Netly.Core namespace >> Netly
- Netly.Core.MainThread class >> Netly.Ny.MainThread

Description

Syntax

Netly syntax was updated... Code below!

#OLD

# instance
TcpClient <instance> = new TcpClient(...);
TcpServer <instance> = new TcpServer(...);
UdpClient <instance> = new UdpClient(...);
UdpServer <instance> = new UdpServer(...);

# propriety
<value> = <instance>.IsOpened;
<value> = <instance>.Host;

# invokes
<instance>.Open(...);
<instance>.Close(...);

# callbacks
<instance>.On<...>((...) => { ... });
<instance>.OnData((...) =>  { ... }); 
<instance>.OnOpen(() => { ... });

#NEW

# instance
TCP.Client <instance> = new TCP.Client(...);
TCP.Server <instance> = new TCP.Server(...);
UDP.Client <instance> = new UDP.Client(...);
UDP.Server <instance> = new UDP.Server(...);

# propriety
<value> = <instance>.IsOpened;
<value> = <instance>.Host;

# invokes
<instance>.To.Open(...);
<instance>.To.Close(...);

# callbacks
<instance>.On.<...>((...) => { ... });
<instance>.On.Data((...) =>  { ... }); 
<instance>.On.Open(() => { ... });

# OLD

bytes[] <value> = NE.GetBytes("hello world", NE.Mode.UTF8);
string[] <value> = NE.GetString(new byte[]{ 1, 2, 3 }, NE.Mode.UTF8);

# NEW
using Byter;

bytes[] <value> = "hello world".GetBytes();
bytes[] <value> = "hello world".GetBytes(Encoding.UTF8);
string[] <value> = new byte[] { 1, 2, 3 }.GetString();
string[] <value> = new byte[] { 1, 2, 3 }.GetString(Encoding.UTF8);

HTTP

Server (HTTP & WebSocket)

HTTP.Server server  = new HTTP.Server();

# callbacks
server.On.Open(() => { ... });
server.On.Error((exception) => { ... });
server.On.Close(() => { ... });

# map http method routes
server.Map.Get("/", (request, response) => { ... });
server.Map.Post("/login", (request, response) => { ... });
server.Map.Delete("/ban/{id}/"(request, response) => { ... });
server.Map.Put("/update/{id}/", (request, response) => { ... });
server.Map.Patch("/update/{id}/", (request, response) => { ... });
server.Map.Head("validate/{token}/", (request, response) => { ... });
server.Map.All("/ping", (request, response) => { ... }); # handle all http method

# global middleware
server.Middleware.Add((request, response, next) => { ... });

# local middleware
server.Middleware.Add("/admin/", (request, response, next) => { ... });
server.Middleware.Add("/app/{foo}/{bar}/", (request, response, next) => { ... });

# websocket server
server.Map.Websocket("/chat/echo", (request, websocket) => { ... });
server.Map.Websocket("/chat/pingpong", (request, websocket) => { ... });
server.Map.Websocket("/chat/echo/{token}/", (request, websocket) => { ... });

# actions
server.To.Open(new Uri("http://localhost.com"));
server.To.Close();

RUDP

Namespace Update

// removed (Netly.Core is moved for Netly)
using Netly.Core;

// Added (netly interfaces namespace)
using Netly.Interfaces;

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
```
Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz

Base speed:	2.30 GHz
Sockets:	1
Cores:	12
Logical processors:	24
Virtualisation:	Enabled
L1 cache:	768 KB
L2 cache:	3.0 MB
L3 cache:	30.0 MB
```
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.

What's Changed

Bump xunit from 2.4.2 to 2.7.1 by @dependabot in #40
Bump coverlet.collector from 3.1.2 to 6.0.2 by @dependabot in #39
Bump Microsoft.NET.Test.Sdk from 17.3.2 to 17.9.0 by @dependabot in #41
Bump xunit.runner.visualstudio from 2.4.5 to 2.5.8 by @dependabot in #42
Bump xunit from 2.7.1 to 2.8.0 by @dependabot in #44
Bump xunit.runner.visualstudio from 2.5.8 to 2.8.0 by @dependabot in #45
Bump Microsoft.NET.Test.Sdk from 17.9.0 to 17.10.0 by @dependabot in #50
Bump xunit from 2.8.0 to 2.8.1 by @dependabot in #52
Bump xunit.runner.visualstudio from 2.8.0 to 2.8.1 by @dependabot in #51
Bump xunit.runner.visualstudio from 2.8.1 to 2.8.2 by @dependabot in #57
Bump xunit from 2.8.1 to 2.9.0 by @dependabot in #56
Bump Microsoft.NET.Test.Sdk from 17.10.0 to 17.11.0 in /test by @dependabot in #58
Bump Microsoft.NET.Test.Sdk from 17.11.0 to 17.11.1 in /test by @dependabot in #62
Bump xunit from 2.9.0 to 2.9.2 in /test by @dependabot in #65
Bump the npm_and_yarn group across 1 directory with 4 updates by @dependabot in #66
Bump Microsoft.NET.Test.Sdk from 17.11.1 to 17.12.0 in /test by @dependabot in #69
Bump the npm_and_yarn group across 1 directory with 3 updates by @dependabot in #70
Bump Byter from 3.0.0 to 4.0.0 in /test by @dependabot in #71
Bump nanoid from 3.3.7 to 3.3.8 in /docs in the npm_and_yarn group across 1 directory by @dependabot in #72
Bump xunit.runner.visualstudio from 2.8.2 to 3.0.0 in /test by @dependabot in #73
Bump coverlet.collector from 6.0.2 to 6.0.3 in /test by @dependabot in #74
Bump xunit from 2.9.2 to 2.9.3 in /test by @dependabot in #75
Bump xunit.runner.visualstudio from 3.0.0 to 3.0.1 in /test by @dependabot in #78
Bump katex from 0.16.11 to 0.16.21 in /docs in the npm_and_yarn group across 1 directory by @dependabot in #79
Bump prismjs from 1.29.0 to 1.30.0 in ...