A concrete implementation of the System.Net.WebSockets.WebSocket abstract,
that allows you to make WebSocket connections as a client or to respond to WebSocket requests as a server
(or wrap existing WebSocket connections of ASP.NET / ASP.NET Core).
NuGet
Walking on the ground
The class ManagedWebSocket is an implementation or a wrapper of the System.Net.WebSockets.WebSocket abstract class,
that allows you send and receive messages in the same way for both side of client and server role.
Receiving messages:
async Task ReceiveAsync(ManagedWebSocket websocket)
{
var buffer = new ArraySegment<byte>(new byte[1024]);
while (true)
{
WebSocketReceiveResult result = await websocket.ReceiveAsync(buffer, CancellationToken.None).ConfigureAwait(false);
switch (result.MessageType)
{
case WebSocketMessageType.Close:
return;
case WebSocketMessageType.Text:
case WebSocketMessageType.Binary:
var value = Encoding.UTF8.GetString(buffer, result.Count);
Console.WriteLine(value);
break;
}
}
}
Sending messages:
async Task SendAsync(ManagedWebSocket websocket)
{
var buffer = new ArraySegment<byte>(Encoding.UTF8.GetBytes("Hello World"));
await websocket.SendAsync(buffer, WebSocketMessageType.Text, true, CancellationToken.None).ConfigureAwait(false);
}
Useful properties:
// the identity of the connection
public Guid ID { get; }
// true if the connection was made when connect to a remote endpoint (mean client role)
public bool IsClient { get; }
// original requesting URI of the connection
public Uri RequestUri { get; }
// the time when the connection is established
public DateTime Timestamp { get; }
// the remote endpoint
public EndPoint RemoteEndPoint { get; }
// the local endpoint
public EndPoint LocalEndPoint { get; }
// Extra information
public Dictionary<string, object> Extra { get; }
// Headers information
public Dictionary<string, string> Headers { get; }
Fly on the sky with Event-liked driven
Using the WebSocket class
This is a centralized element for working with both side of client and server role.
This class has 04 action properties (event handlers) to take care of all working cases, you just need to assign your code to cover its.
// fire when got any error
Action<ManagedWebSocket, Exception> OnError;
// fire when a connection is established
Action<ManagedWebSocket> OnConnectionEstablished;
// fire when a connection is broken
Action<ManagedWebSocket> OnConnectionBroken;
// fire when a message is received
Action<ManagedWebSocket, WebSocketReceiveResult, byte[]> OnMessageReceived;
Example:
var websocket = new WebSocket
{
OnError = (webSocket, exception) =>
{
// your code to handle error
},
OnConnectionEstablished = (webSocket) =>
{
// your code to handle established connection
},
OnConnectionBroken = (webSocket) =>
{
// your code to handle broken connection
},
OnMessageReceived = (webSocket, result, data) =>
{
// your code to handle received message
}
};
And this class has some methods for working on both side of client and server role:
Use the Connect method to connect to a remote endpoint
WebSocket server
Use the StartListen method to start the listener to listen incoming connection requests.
Use the StopListen method to stop the listener.
WebSocket server with Secure WebSockets (wss://)
Enabling secure connections requires two things:
Pointing certificate to an x509 certificate that containing a public and private key.
Using the scheme wss instead of ws (or https instead of http) on all clients
var websocket = new WebSocket
{
Certificate = new X509Certificate2("my-certificate.pfx")
// Certificate = new X509Certificate2("my-certificate.pfx", "cert-password", X509KeyStorageFlags.UserKeySet)
};
websocket.StartListen();
Want to have a free SSL certificate? Take a look at Let's Encrypt.
Special: A simple tool named win-acme will help your IIS works with Let's Encrypt very well.
SubProtocol Negotiation
To enable negotiation of subprotocols, specify the supported protocols on SupportedSubProtocols property.
The negotiated subprotocol will be available on the socket's SubProtocol.
If no supported subprotocols are found on the client request (Sec-WebSocket-Protocol), the listener will raises the SubProtocolNegotiationFailedException exception.
var websocket = new WebSocket
{
SupportedSubProtocols = new[] { "messenger", "chat" }
};
websocket.StartListen();
Nagle's Algorithm
The Nagle's Algorithm is disabled by default (to send a message immediately).
If you want to enable the Nagle's Algorithm, set NoDelay to false
var websocket = new WebSocket
{
NoDelay = false
};
websocket.StartListen();
Wrap an existing WebSocket connection of ASP.NET / ASP.NET Core
When integrate this component with your app that hosted by ASP.NET / ASP.NET Core, you might want to use the WebSocket connections of ASP.NET / ASP.NET Core directly,
then the method WrapAsync is here to help. This method will return a task that run a process for receiving messages from this WebSocket connection.
And might be you need an extension method to wrap an existing WebSocket connection, then take a look at some lines of code below:
ASP.NET
public static Task WrapAsync(this net.vieapps.Components.WebSockets.WebSocket websocket, AspNetWebSocketContext context)
{
var serviceProvider = (IServiceProvider)HttpContext.Current;
var httpWorker = serviceProvider?.GetService<HttpWorkerRequest>();
var remoteAddress = httpWorker == null ? context.UserHostAddress : httpWorker.GetRemoteAddress();
var remotePort = httpWorker == null ? 0 : httpWorker.GetRemotePort();
var remoteEndpoint = IPAddress.TryParse(remoteAddress, out IPAddress ipAddress)
? new IPEndPoint(ipAddress, remotePort > 0 ? remotePort : context.RequestUri.Port) as EndPoint
: new DnsEndPoint(context.UserHostName, remotePort > 0 ? remotePort : context.RequestUri.Port) as EndPoint;
var localAddress = httpWorker == null ? context.RequestUri.Host : httpWorker.GetLocalAddress();
var localPort = httpWorker == null ? 0 : httpWorker.GetLocalPort();
var localEndpoint = IPAddress.TryParse(localAddress, out ipAddress)
? new IPEndPoint(ipAddress, localPort > 0 ? localPort : context.RequestUri.Port) as EndPoint
: new DnsEndPoint(context.RequestUri.Host, localPort > 0 ? localPort : context.RequestUri.Port) as EndPoint;
return websocket.WrapAsync(context.WebSocket, context.RequestUri, remoteEndpoint, localEndpoint);
}
ASP.NET Core
public static async Task WrapAsync(this net.vieapps.Components.WebSockets.WebSocket websocket, HttpContext context)
{
if (context.WebSockets.IsWebSocketRequest)
{
var webSocket = await context.WebSockets.AcceptWebSocketAsync().ConfigureAwait(false);
var requestUri = new Uri($"{context.Request.Scheme}://{context.Request.Host}{context.Request.Path}{context.Request.PathBase}{context.Request.QueryString}");
var remoteEndPoint = new IPEndPoint(context.Connection.RemoteIpAddress, context.Connection.RemotePort);
var localEndPoint = new IPEndPoint(context.Connection.LocalIpAddress, context.Connection.LocalPort);
await websocket.WrapAsync(webSocket, requestUri, remoteEndPoint, localEndPoint).ConfigureAwait(false);
}
}
While working with ASP.NET Core, we think that you need a middle-ware to handle all request of WebSocket connections, just look like this:
public class WebSocketMiddleware
{
readonly RequestDelegate _next;
net.vieapps.Components.WebSockets.WebSocket _websocket;
public WebSocketMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
{
var logger = loggerFactory.CreateLogger<WebSocketMiddleware>();
this._websocket = new net.vieapps.Components.WebSockets.WebSocket(loggerFactory)
{
OnError = (websocket, exception) =>
{
logger.LogError(exception, $"Got an error: {websocket?.ID} @ {websocket?.RemoteEndPoint} => {exception.Message}");
},
OnConnectionEstablished = (websocket) =>
{
logger.LogDebug($"Connection is established: {websocket.ID} @ {websocket.RemoteEndPoint}");
},
OnConnectionBroken = (websocket) =>
{
logger.LogDebug($"Connection is broken: {websocket.ID} @ {websocket.RemoteEndPoint}");
},
OnMessageReceived = (websocket, result, data) =>
{
var message = result.MessageType == System.Net.WebSockets.WebSocketMessageType.Text ? data.GetString() : "(binary message)";
logger.LogDebug($"Got a message: {websocket.ID} @ {websocket.RemoteEndPoint} => {message}");
}
};
this._next = next;
}
public async Task Invoke(HttpContext context)
{
await this._websocket.WrapAsync(context).ConfigureAwait(false);
await this._next.Invoke(context).ConfigureAwait(false);
}
}
And remember to tell APS.NET Core uses your middleware (at Configure method of Startup.cs)
Messages are received automatically via parallel tasks, and you only need to assign OnMessageReceived event for handling its.
Sending messages are the same as ManagedWebSocket, with a little different: the first argument - you need to specify a WebSocket connection (by an identity) for sending your messages.
16K is default size of the protocol buffer for receiving messages (its large enough for most case because we are usually use WebSocket to send/receive small data). If you want to change (to receive large messages), then set a new value for the static property named ReceiveBufferSize of the WebSocket class.
Serilog.Extensions.Logging: rolling log files (by hour or date - Serilog.Sink.File) - high performance, and very simple to use
Namespaces
using net.vieapps.Components.Utility;
using net.vieapps.Components.WebSockets;
A very simple stress test
Environment
01 server with Windows 2012 R2 x64 on Intel Xeon E3-1220 v3 3.1GHz - 8GB RAM
05 clients with Windows 10 x64 and Ubuntu Linux 16.04 x64
The scenario
Clients (05 stations) made 20,000 concurrent connections to the server, all connections are secured (use Let's Encrypt SSL certificate)
Clients send 02 messages per second to server (means server receives 40,000 messages/second) - size of 01 message: 1024 bytes (1K)
Server sends 01 message to all connections (20,000 messages) each 10 minutes - size of 01 message: 1024 bytes (1K)
The results
Server is still alive after 01 week (60 * 24 * 7 = 10,080 minutes)
No dropped connection
No hang
Used memory: 1.3 GB - 1.7 GB
CPU usages: 3% - 15% while receiving messages, 18% - 35% while sending messages
Performance Tuning
While working directly with this component, performance is not your problem, but when you wrap WebSocket connections of ASP.NET
or ASP.NET Core (with IIS Integration), may be you reach max 5,000 concurrent connections (because IIS allows 5,000 CCU by default).
ASP.NET and IIS scale very well, but you'll need to change a few settings to set up your server for lots of concurrent connections,
as opposed to lots of requests per second.
IIS Configuration
Max concurrent requests per application
Increase the number of concurrent requests IIS will serve at once:
Open an administrator command prompt at %windir%\System32\inetsrv
Run the command below to update the appConcurrentRequestLimit attribute to a suitable number (5000 is the default in IIS7+)
Example:
appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:100000
ASP.NET Configuration
Maximum Concurrent Requests Per CPU
By default ASP.NET 4.0 sets the maximum concurrent connections to 5000 per CPU.
If you need more concurrent connections then you need to increase the maxConcurrentRequestsPerCPU setting.
Open %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config (Framework64 for 64 bit processes)
Copy from the sample below (ensure case is correct!)
When the total amount of connections exceed the maxConcurrentRequestsPerCPU setting (i.e. maxConcurrentRequestsPerCPU * number of logical processors),
ASP.NET will start throttling requests using a queue. To control the size of the queue, you can tweak the requestQueueLimit.
Open %windir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config (Framework64 for 64 bit processes)
Locate the processModel element
Set the autoConfig attribute to false and the requestQueueLimit attribute to a suitable number
