How to Build a High-Performance TCP Server from Scratch

Building a high-performance TCP server requires a deep understanding of how sockets work and how to manage connections efficiently. In this blog post, we’ll take a close look at the .NET Socket class, uncovering how it's implemented. By understanding these details, we can leverage its full potential to build a TCP server capable of handling high-throughput, low-latency communication, especially for scenarios like receiving heartbeat messages from numerous IoT devices. We’ll also compare the performance of our custom server with Kestrel, the highly optimised ASP.NET web server, to demonstrate that a well-crafted .NET socket server can match its efficiency. Join me as we dive into the architecture of .NET sockets and see how to create a high-performance, low-latency TCP server that delivers results on par with Kestrel. The code is accessible in the accompanying GitHub repository. Heartbeat TCP Server Our TCP server will handle heartbeat messages from thousands of IoT devices, each periodically sending a small HTTP/1.1 request that contains a header with its unique Device-Id . Upon receiving a heartbeat, the server will update the last known timestamp for that device in an in-memory data structure, send an HTTP 201 status code to acknowledge the receipt, and then close the TCP connection. curl -X PUT -H "Device-Id: 1234" -v 127.0.0.1:9096 * Trying 127.0.0.1:9096... * Connected to 127.0.0.1 (127.0.0.1) port 9096 > PUT / HTTP/1.1 > Host: 127.0.0.1:9096 > User-Agent: curl/8.8.0 > Accept: */* > Device-Id: 1234 > < HTTP/1.1 204 No Content < * Connection #0 to host 127.0.0.1 left intact The goal is to build a high-performance TCP server, with two key metrics in mind: latency and throughput. Latency refers to the time taken to receive and process a new heartbeat message — updating the last known timestamp in memory. Reducing latency improves the server’s responsiveness. Throughput, on the other hand, measures how many heartbeat messages the server can process in a given time. Increasing throughput allows the server to handle more IoT devices, improving overall efficiency. Balancing these two metrics is critical, as high throughput doesn’t necessarily mean low latency. Optimising both ensures the server performs well under load. Socket To implement our server, we’ll use Socket, which is an abstraction provided by the operating system to facilitate network communication. Both the client and server must create and manage sockets to exchange data. In .NET, the Socket class from the System.Net.Sockets namespace acts as a managed wrapper around the OS's native socket functionality, providing a convenient interface for establishing and managing network connections. Initialise a Server Socket The following code initialises a TCP socket, binding it to a specific IP address and port. By calling the Listen method, the server signals the operating system to begin queuing incoming connections. The backlog parameter defines how many connections the OS will hold in the queue. However, while the OS can queue connections, the server still needs to actively accept them. To do this, the server calls the Accept method, which dequeues a connection and returns a new socket dedicated to that connection. This new socket can then be used for sending and receiving data, while the original socket continues listening for additional connections. var listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); listenerSocket.Bind(new IPEndPoint(IPAddress.Any, _port)); listenerSocket.Listen(backlog: 4096); while (true) { var acceptSocket = listenerSocket.Accept(); HandleNewConnection(acceptSocket); // sequential model } Handling New Connections The simplest approach to handle new connections is through a sequential model as we saw, where the server processes one request at a time. It accepts a connection, handles it completely, and then moves on to the next. While easy to implement, this model is inefficient when multiple clients try to connect simultaneously, as only one client can interact with the server at any given time. This forces other clients to wait, leading to delays and poor performance, especially under heavy load. To improve throughput and reduce latency, concurrency is key. Concurrency allows the server to handle multiple requests at once, treating each request as an independent task that can be processed in parallel. There are two main concurrency models: processes and threads. Processes are more isolated, each running in its own memory space with separate resources. While this isolation increases security and stability, it makes processes slower and more resource-intensive. Communication between processes often requires complex mechanisms like inter-process communication (IPC). Threads, on the other hand, are lightweight and share the same memory space within a single process, allowing for faster and more efficient communication. Since threads operate within the same process, they are better suited for handling multiple connections in a TCP server, where concurrency is critical. Threads enable the server to manage several tasks simultaneously with lower overhead, making them ideal for high-performance environments. A common strategy is to create a new thread for each incoming connection, allowing the server to handle each request independently in its own thread, as shown in the following code. while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var thread = new Thread(() => HandleNewConnection(acceptSocket)); thread.Start(); } Thread Pool To boost server performance, a thread pool reuses long-running worker threads, reducing the overhead of creating new threads for each task. Instead of managing individual threads, a thread pool assigns tasks to available threads, making it more efficient, especially for short-lived tasks. In .NET, you can use ThreadPool.QueueUserWorkItem or ThreadPool.UnsafeQueueUserWorkItem to queue tasks. The key difference is that QueueUserWorkItem passes the security context to the thread, ensuring safer execution, while UnsafeQueueUserWorkItem skips this for faster performance but with potential security risks. Setting preferLocal to false ensures tasks are distributed evenly across all threads, improving load balancing in high-concurrency scenarios. while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var handler = new ConnectionHandler(acceptSocket); ThreadPool.UnsafeQueueUserWorkItem(handler, preferLocal: false); } class ConnectionHandler : IThreadPoolWorkItem { Socket _acceptSocket; public ConnectionHandler(Socket acceptSocket) { _acceptSocket = acceptSocket; } public void Execute() { HandleNewConnection(_acceptSocket); } } Blocking vs Non-Blocking IO After accepting a connection, a server uses the socket to read from and write to the client. In blocking I/O, each read operation suspends the thread until data arrives, causing the thread to wait and preventing it from handling other tasks. This can lead to high context-switching overhead as the number of threads increases, reducing overall throughput and scalability. Non-blocking I/O allows the server to request data without waiting for it to arrive. For example, a non-blocking read initiates the request and continues executing other code, such as handling additional connections, while waiting for data. This method enhances efficiency by not tying up threads during I/O operations. However, non-blocking I/O can involve busy-waiting, where the server continuously checks the status of multiple sockets, which can be inefficient. For instance, with thousands of sockets, constantly polling each one — even if only the last one has data — can lead to excessive CPU usage and diminished performance. while (true) { foreach (var socket in sockets) { data = socket.nonBlockingRead(); if (data is not null) { ProcessData(data); } } } Event-driven multiplexing To overcome the inefficiencies of busy-waiting in non-blocking I/O, modern systems use I/O multiplexing with an event-driven model. This approach leverages an event loop and callbacks to efficiently manage multiple I/O operations. In this model, the application registers interest in specific events (e.g., data availability or readiness to write) for each socket. The event loop waits for notifications from the operating system about these events instead of continuously polling each socket. When an event occurs, the event loop triggers a callback function to handle the I/O operation, allowing the application to respond as needed. This pattern, known as the reactor pattern, reduces CPU usage and overhead by eliminating constant polling. It efficiently handles thousands of connections by focusing only on active, ready-to-process connections, making it ideal for high-performance and responsive network servers. foreach (var socket in sockets) { OS.EventRegistration(socket, callback, event_type: read | write); } // event loop while (true) { events = OS.WaitForSocketEvents(); foreach (var event in events) { event.callback_function(event.socket, event_type); } } Event-Driven Sockets in .NET In .NET, socket operations on Unix-based systems (like Linux) are managed using an event-driven model, facilitated by the SocketAsyncEngine class. This class implements an event loop that listens for notifications from the operating system’s native mechanisms, such as epoll on Linux or kqueue on macOS. When these notifications are received, the event loop schedules the corresponding socket operations (e.g., reads and writes) as work items in the ThreadPool. The following code provides a simplified example of how the event loop is implemented by SocketAsyncEngine. class SocketAsyncEngine : IThreadPoolWorkItem { ConcurrentQueue eventQueue = _eventQueue; static private SocketAsyncEngine() { var thread = new Thread(static s => ((SocketAsyncEngine)s!).EventLoop()) { IsBackground = true, Name = ".NET Sockets" }; thread.UnsafeStart(this); } private void EventLoop() { SocketEventHandler handler = new SocketEventHandler(this); while (true) { Interop.Sys.WaitForSocketEvents(_port, handler.Buffer, &numEvents); if (handler.HandleSocketEvents(numEvents)) { ThreadPool.UnsafeQueueUserWorkItem(this, preferLocal: false); } } } void void Execute() { while (true) { if (eventQueue.TryDequeue(out ev)) { break; } ev.Context.HandleEvents(ev.Events); } } } To register a callback for non-blocking socket operations such as Receive or Send in .NET, we use the SocketAsyncEventArgs class. This class allows us to associate a callback with the socket operation, which is triggered when the event loop detects a relevant event. The code snippet below demonstrates how to use SocketAsyncEventArgs for this purpose: var eventArgs = new SocketAsyncEventArgs(unsafeSuppressExecutionContextFlow:true); eventArgs.SetBuffer(buffer); eventArgs.Completed += RecvEventArg_Completed; acceptSocket.ReceiveAsync(receiveEventArgs); void RecvEventArg_Completed(object? sender, SocketAsyncEventArgs e) { // consumeing buffer } When a read event occurs for a specific socket, the event loop triggers the registered callback via the SocketAsyncEventArgs.Completed event. Additionally, the Receive method captures the execution context to ensure it can be restored before executing the callback. For improved performance, you can disable the execution context if it’s not needed by configuring SocketAsyncEventArgs accordingly in its constructor. For asynchronous operations like ReceiveAsync that do not take a SocketAsyncEventArgs parameter, .NET internally creates a new SocketAsyncEventArgs object. These methods return a ValueTask, which signals the runtime to proceed once the operation is completed and the underlying SocketAsyncEventArgs object is done. SocketAsyncEventArgs Pool Reusing SocketAsyncEventArgs objects from a pool can improve performance by avoiding the overhead of creating new instances for each socket event. However, pooling should be used carefully. If a pooled object is far from the CPU core’s cache, accessing it may cause delays. In some cases, creating a new object might be faster than using a cached one. The key is to measure and balance the trade-offs between pooling and performance, ensuring the pool enhances rather than hinders efficiency. Inline Completion In .NET, socket continuations are usually dispatched to the ThreadPool from the event thread to prevent blocking the event handling loop. However, by setting PreferInlineCompletions to true, continuations can be executed directly on the event thread, reducing the overhead of dispatching to the ThreadPool. By default, PreferInlineCompletions is set to false. You can enable inline completions by setting the DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS environment variable to 1. bool HandleEvents(Event[] events) { foreach(var event in envents) { if(PreferInlineCompletions) { event.Callback(); } else { ThreadPool.UnsafeQueueUserWorkItem(event.Callback, preferLocal: false); } } } Socket File Descriptors Each time an application creates a new socket on Linux, the operating system generates a file descriptor, an integer that represents the created socket. In .NET, you can access this file descriptor to make direct system calls, but this approach requires caution. The file descriptor becomes invalid once the socket is closed, and using it after that can lead to errors or undefined behaviour. In .NET, the SafeSocketHandle property of a Socket contains this file descriptor. To access its value, you can use the DangerousGetHandle() method of SafeSocketHandle. Event-Based Heartbeat Server Now that we’ve covered the key concepts and building blocks, you can see everything in action in the event-based server I’ve implemented. This server handles heartbeat requests and is fully configurable — you can enable or disable features like inline completions or socket pooling using the corresponding option values. To get started, clone the repository and run the server using the following command: cd src dotnet run -c Release --InlineCompletions false --SocketPolling false Once you run the server, you should see the following output in your terminal, indicating that it’s ready for action: Server started ServerOptions: Port=9096, Address=0.0.0.0, MaxRequestSizeInByte=512, InlineCompletions=False, SocketPolling=False At this point, the server is live, and you’re ready to run your benchmarks to test its performance! Benchmarking the TCP Server To ensure our TCP server performs well, we need to measure its throughput and latency. We’ll compare its performance against a baseline, the same Heartbeat server built using .NET Kestrel. Kestrel is highly optimised in the .NET ecosystem, and while our server is purpose-built, this comparison helps us verify that we’re using sockets efficiently. For benchmarking, we used Bombardier, a widely used fast HTTP benchmarking tool also employed by the .NET team in the Crank project to measure Kestrel’s performance. To establish the baseline, I created a simple ASP.NET application exposing a minimal endpoint for handling heartbeat messages. Our tests will make HTTP requests to both the heartbeat server and the baseline Kestrel server. Since IoT devices establish new TCP connections for each heartbeat, we need to simulate this behavior by ensuring each test request creates a new TCP client connection. Unlike Kestrel, which supports connection reuse (keep-alive), our server closes the connection after every request. Here’s the command we used to run the benchmark: ~$ bombardier -c 32 -m PUT -H "Device-Id:1234" --http1 -a 127.0.0.1:9096 Bombarding http://127.0.0.1:9096 for 10s using 32 connection(s) [==================================================================================================================] 10s Done! Statistics Avg Stdev Max Reqs/sec 10114.69 1085.95 12151.48 Latency 3.13ms 0.96ms 20.28ms HTTP codes: 1xx - 0, 2xx - 101093, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 1.84MB/s While the default output is shown above, in our actual benchmarking, we used JSON output for easier parsing and charting. Benchmark Results The benchmark was run 35 times, with the first 5 iterations discarded as warm-up. We tested with varying numbers of connections: 1, 16, 32, 128, and 256 concurrent connections. In all scenarios, the custom heartbeat server outperformed the baseline Kestrel server, both in terms of latency and throughput (requests per minute). This demonstrates that our event-based server, despite being purpose-built, handles high connection loads more efficiently than the baseline, proving that our socket implementation is well-optimised. The following chart provides a comprehensive overview of the results: Wrap Up In this post, we demonstrate the process of building a high-performance TCP server using .NET’s Socket class to handle heartbeat messages from IoT devices. We take a deep dive into socket handling, connection management, concurrency models, and efficient I/O techniques like event-driven programming. We explore the custom TCP server with both blocking and non-blocking I/O, along with advanced techniques such as thread pooling and socket multiplexing. Finally, we benchmark the server against the highly-optimised Kestrel server and show how a well-crafted, event-driven architecture can outperform Kestrel in handling high connection loads while maintaining low latency. Next Step: Moving forward, we can further explore the data handling aspect by examining efficient ways to manage and consume buffers. This will allow for more optimised processing of incoming data, enhancing the server’s overall performance. Building a high-performance TCP server requires a deep understanding of how sockets work and how to manage connections efficiently. In this blog post, we’ll take a close look at the .NET Socket class, uncovering how it's implemented. By understanding these details, we can leverage its full potential to build a TCP server capable of handling high-throughput, low-latency communication, especially for scenarios like receiving heartbeat messages from numerous IoT devices. Socket We’ll also compare the performance of our custom server with Kestrel, the highly optimised ASP.NET web server, to demonstrate that a well-crafted .NET socket server can match its efficiency. Join me as we dive into the architecture of .NET sockets and see how to create a high-performance, low-latency TCP server that delivers results on par with Kestrel. The code is accessible in the accompanying GitHub repository . GitHub repository GitHub repository Heartbeat TCP Server Our TCP server will handle heartbeat messages from thousands of IoT devices, each periodically sending a small HTTP/1.1 request that contains a header with its unique Device-Id . Upon receiving a heartbeat, the server will update the last known timestamp for that device in an in-memory data structure, send an HTTP 201 status code to acknowledge the receipt, and then close the TCP connection. Device-Id curl -X PUT -H "Device-Id: 1234" -v 127.0.0.1:9096 * Trying 127.0.0.1:9096... * Connected to 127.0.0.1 (127.0.0.1) port 9096 > PUT / HTTP/1.1 > Host: 127.0.0.1:9096 > User-Agent: curl/8.8.0 > Accept: */* > Device-Id: 1234 > PUT / HTTP/1.1 > Host: 127.0.0.1:9096 > User-Agent: curl/8.8.0 > Accept: */* > Device-Id: 1234 > < HTTP/1.1 204 No Content < * Connection #0 to host 127.0.0.1 left intact The goal is to build a high-performance TCP server, with two key metrics in mind: latency and throughput . Latency refers to the time taken to receive and process a new heartbeat message — updating the last known timestamp in memory. Reducing latency improves the server’s responsiveness. Throughput, on the other hand, measures how many heartbeat messages the server can process in a given time. Increasing throughput allows the server to handle more IoT devices, improving overall efficiency. latency throughput Balancing these two metrics is critical, as high throughput doesn’t necessarily mean low latency. Optimising both ensures the server performs well under load. Socket To implement our server, we’ll use Socket , which is an abstraction provided by the operating system to facilitate network communication. Both the client and server must create and manage sockets to exchange data. In .NET, the Socket class from the System.Net.Sockets namespace acts as a managed wrapper around the OS's native socket functionality, providing a convenient interface for establishing and managing network connections. Socket Socket System.Net.Sockets Initialise a Server Socket The following code initialises a TCP socket, binding it to a specific IP address and port. By calling the Listen method, the server signals the operating system to begin queuing incoming connections. The backlog parameter defines how many connections the OS will hold in the queue. However, while the OS can queue connections, the server still needs to actively accept them. Listen backlog To do this, the server calls the Accept method, which dequeues a connection and returns a new socket dedicated to that connection. This new socket can then be used for sending and receiving data, while the original socket continues listening for additional connections. Accept var listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); listenerSocket.Bind(new IPEndPoint(IPAddress.Any, _port)); listenerSocket.Listen(backlog: 4096); while (true) { var acceptSocket = listenerSocket.Accept(); HandleNewConnection(acceptSocket); // sequential model } var listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); listenerSocket.Bind(new IPEndPoint(IPAddress.Any, _port)); listenerSocket.Listen(backlog: 4096); while (true) { var acceptSocket = listenerSocket.Accept(); HandleNewConnection(acceptSocket); // sequential model } Handling New Connections The simplest approach to handle new connections is through a sequential model as we saw, where the server processes one request at a time. It accepts a connection, handles it completely, and then moves on to the next. While easy to implement, this model is inefficient when multiple clients try to connect simultaneously, as only one client can interact with the server at any given time. This forces other clients to wait, leading to delays and poor performance, especially under heavy load. To improve throughput and reduce latency, concurrency is key. Concurrency allows the server to handle multiple requests at once, treating each request as an independent task that can be processed in parallel. Concurrency There are two main concurrency models: processes and threads . processes threads Processes are more isolated, each running in its own memory space with separate resources. While this isolation increases security and stability, it makes processes slower and more resource-intensive. Communication between processes often requires complex mechanisms like inter-process communication (IPC). Threads, on the other hand, are lightweight and share the same memory space within a single process, allowing for faster and more efficient communication. Since threads operate within the same process, they are better suited for handling multiple connections in a TCP server, where concurrency is critical. Threads enable the server to manage several tasks simultaneously with lower overhead, making them ideal for high-performance environments. Processes are more isolated, each running in its own memory space with separate resources. While this isolation increases security and stability, it makes processes slower and more resource-intensive. Communication between processes often requires complex mechanisms like inter-process communication (IPC). Processes Threads , on the other hand, are lightweight and share the same memory space within a single process, allowing for faster and more efficient communication. Since threads operate within the same process, they are better suited for handling multiple connections in a TCP server, where concurrency is critical. Threads enable the server to manage several tasks simultaneously with lower overhead, making them ideal for high-performance environments. Threads A common strategy is to create a new thread for each incoming connection, allowing the server to handle each request independently in its own thread, as shown in the following code. while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var thread = new Thread(() => HandleNewConnection(acceptSocket)); thread.Start(); } while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var thread = new Thread(() => HandleNewConnection(acceptSocket)); thread.Start(); } Thread Pool To boost server performance, a thread pool reuses long-running worker threads, reducing the overhead of creating new threads for each task. Instead of managing individual threads, a thread pool assigns tasks to available threads, making it more efficient, especially for short-lived tasks. thread pool In .NET, you can use ThreadPool.QueueUserWorkItem or ThreadPool.UnsafeQueueUserWorkItem to queue tasks. The key difference is that QueueUserWorkItem passes the security context to the thread, ensuring safer execution, while UnsafeQueueUserWorkItem skips this for faster performance but with potential security risks. ThreadPool.QueueUserWorkItem ThreadPool.UnsafeQueueUserWorkItem QueueUserWorkItem UnsafeQueueUserWorkItem Setting preferLocal to false ensures tasks are distributed evenly across all threads, improving load balancing in high-concurrency scenarios. preferLocal false while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var handler = new ConnectionHandler(acceptSocket); ThreadPool.UnsafeQueueUserWorkItem(handler, preferLocal: false); } class ConnectionHandler : IThreadPoolWorkItem { Socket _acceptSocket; public ConnectionHandler(Socket acceptSocket) { _acceptSocket = acceptSocket; } public void Execute() { HandleNewConnection(_acceptSocket); } } while (true) { var acceptSocket = listenerSocket.Accept(); // concurrent model var handler = new ConnectionHandler(acceptSocket); ThreadPool.UnsafeQueueUserWorkItem(handler, preferLocal: false); } class ConnectionHandler : IThreadPoolWorkItem { Socket _acceptSocket; public ConnectionHandler(Socket acceptSocket) { _acceptSocket = acceptSocket; } public void Execute() { HandleNewConnection(_acceptSocket); } } Blocking vs Non-Blocking IO Blocking vs Non-Blocking IO After accepting a connection, a server uses the socket to read from and write to the client. In blocking I/O , each read operation suspends the thread until data arrives, causing the thread to wait and preventing it from handling other tasks. This can lead to high context-switching overhead as the number of threads increases, reducing overall throughput and scalability. blocking I/O Non-blocking I/O allows the server to request data without waiting for it to arrive. For example, a non-blocking read initiates the request and continues executing other code, such as handling additional connections, while waiting for data. This method enhances efficiency by not tying up threads during I/O operations. Non-blocking I/O However, non-blocking I/O can involve busy-waiting, where the server continuously checks the status of multiple sockets, which can be inefficient. For instance, with thousands of sockets, constantly polling each one — even if only the last one has data — can lead to excessive CPU usage and diminished performance. while (true) { foreach (var socket in sockets) { data = socket.nonBlockingRead(); if (data is not null) { ProcessData(data); } } } while (true) { foreach (var socket in sockets) { data = socket.nonBlockingRead(); if (data is not null) { ProcessData(data); } } } Event-driven multiplexing To overcome the inefficiencies of busy-waiting in non-blocking I/O, modern systems use I/O multiplexing with an event-driven model. This approach leverages an event loop and callbacks to efficiently manage multiple I/O operations. In this model, the application registers interest in specific events (e.g., data availability or readiness to write) for each socket. The event loop waits for notifications from the operating system about these events instead of continuously polling each socket. I/O multiplexing When an event occurs, the event loop triggers a callback function to handle the I/O operation, allowing the application to respond as needed. This pattern, known as the reactor pattern , reduces CPU usage and overhead by eliminating constant polling. It efficiently handles thousands of connections by focusing only on active, ready-to-process connections, making it ideal for high-performance and responsive network servers. reactor pattern foreach (var socket in sockets) { OS.EventRegistration(socket, callback, event_type: read | write); } // event loop while (true) { events = OS.WaitForSocketEvents(); foreach (var event in events) { event.callback_function(event.socket, event_type); } } foreach (var socket in sockets) { OS.EventRegistration(socket, callback, event_type: read | write); } // event loop while (true) { events = OS.WaitForSocketEvents(); foreach (var event in events) { event.callback_function(event.socket, event_type); } } Event-Driven Sockets in .NET In .NET, socket operations on Unix-based systems (like Linux) are managed using an event-driven model, facilitated by the SocketAsyncEngine class . This class implements an event loop that listens for notifications from the operating system’s native mechanisms, such as epoll on Linux or kqueue on macOS. When these notifications are received, the event loop schedules the corresponding socket operations (e.g., reads and writes) as work items in the ThreadPool . The following code provides a simplified example of how the event loop is implemented by SocketAsyncEngine . SocketAsyncEngine class epoll kqueue ThreadPool SocketAsyncEngine class SocketAsyncEngine : IThreadPoolWorkItem { ConcurrentQueue eventQueue = _eventQueue; static private SocketAsyncEngine() { var thread = new Thread(static s => ((SocketAsyncEngine)s!).EventLoop()) { IsBackground = true, Name = ".NET Sockets" }; thread.UnsafeStart(this); } private void EventLoop() { SocketEventHandler handler = new SocketEventHandler(this); while (true) { Interop.Sys.WaitForSocketEvents(_port, handler.Buffer, &numEvents); if (handler.HandleSocketEvents(numEvents)) { ThreadPool.UnsafeQueueUserWorkItem(this, preferLocal: false); } } } void void Execute() { while (true) { if (eventQueue.TryDequeue(out ev)) { break; } ev.Context.HandleEvents(ev.Events); } } } class SocketAsyncEngine : IThreadPoolWorkItem { ConcurrentQueue eventQueue = _eventQueue; static private SocketAsyncEngine() { var thread = new Thread(static s => ((SocketAsyncEngine)s!).EventLoop()) { IsBackground = true, Name = ".NET Sockets" }; thread.UnsafeStart(this); } private void EventLoop() { SocketEventHandler handler = new SocketEventHandler(this); while (true) { Interop.Sys.WaitForSocketEvents(_port, handler.Buffer, &numEvents); if (handler.HandleSocketEvents(numEvents)) { ThreadPool.UnsafeQueueUserWorkItem(this, preferLocal: false); } } } void void Execute() { while (true) { if (eventQueue.TryDequeue(out ev)) { break; } ev.Context.HandleEvents(ev.Events); } } } To register a callback for non-blocking socket operations such as Receive or Send in .NET, we use the SocketAsyncEventArgs class. This class allows us to associate a callback with the socket operation, which is triggered when the event loop detects a relevant event. The code snippet below demonstrates how to use SocketAsyncEventArgs for this purpose: Receive Send SocketAsyncEventArgs SocketAsyncEventArgs var eventArgs = new SocketAsyncEventArgs(unsafeSuppressExecutionContextFlow:true); eventArgs.SetBuffer(buffer); eventArgs.Completed += RecvEventArg_Completed; acceptSocket.ReceiveAsync(receiveEventArgs); void RecvEventArg_Completed(object? sender, SocketAsyncEventArgs e) { // consumeing buffer } var eventArgs = new SocketAsyncEventArgs(unsafeSuppressExecutionContextFlow:true); eventArgs.SetBuffer(buffer); eventArgs.Completed += RecvEventArg_Completed; acceptSocket.ReceiveAsync(receiveEventArgs); void RecvEventArg_Completed(object? sender, SocketAsyncEventArgs e) { // consumeing buffer } When a read event occurs for a specific socket, the event loop triggers the registered callback via the SocketAsyncEventArgs.Completed event. Additionally, the Receive method captures the execution context to ensure it can be restored before executing the callback. For improved performance, you can disable the execution context if it’s not needed by configuring SocketAsyncEventArgs accordingly in its constructor. SocketAsyncEventArgs.Completed Receive SocketAsyncEventArgs For asynchronous operations like ReceiveAsync that do not take a SocketAsyncEventArgs parameter, .NET internally creates a new SocketAsyncEventArgs object. These methods return a ValueTask , which signals the runtime to proceed once the operation is completed and the underlying SocketAsyncEventArgs object is done. ReceiveAsync SocketAsyncEventArgs SocketAsyncEventArgs ValueTask SocketAsyncEventArgs SocketAsyncEventArgs Pool Reusing SocketAsyncEventArgs objects from a pool can improve performance by avoiding the overhead of creating new instances for each socket event. However, pooling should be used carefully. If a pooled object is far from the CPU core’s cache, accessing it may cause delays. In some cases, creating a new object might be faster than using a cached one. SocketAsyncEventArgs The key is to measure and balance the trade-offs between pooling and performance, ensuring the pool enhances rather than hinders efficiency. Inline Completion In .NET, socket continuations are usually dispatched to the ThreadPool from the event thread to prevent blocking the event handling loop. However, by setting PreferInlineCompletions to true , continuations can be executed directly on the event thread, reducing the overhead of dispatching to the ThreadPool . ThreadPool PreferInlineCompletions true ThreadPool By default, PreferInlineCompletions is set to false . You can enable inline completions by setting the DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS environment variable to 1 . PreferInlineCompletions false DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS 1 bool HandleEvents(Event[] events) { foreach(var event in envents) { if(PreferInlineCompletions) { event.Callback(); } else { ThreadPool.UnsafeQueueUserWorkItem(event.Callback, preferLocal: false); } } } bool HandleEvents(Event[] events) { foreach(var event in envents) { if(PreferInlineCompletions) { event.Callback(); } else { ThreadPool.UnsafeQueueUserWorkItem(event.Callback, preferLocal: false); } } } Socket File Descriptors Each time an application creates a new socket on Linux, the operating system generates a file descriptor , an integer that represents the created socket. In .NET, you can access this file descriptor to make direct system calls, but this approach requires caution. The file descriptor becomes invalid once the socket is closed, and using it after that can lead to errors or undefined behaviour. file descriptor In .NET, the SafeSocketHandle property of a Socket contains this file descriptor. To access its value, you can use the DangerousGetHandle() method of SafeSocketHandle . SafeSocketHandle Socket DangerousGetHandle() SafeSocketHandle Event-Based Heartbeat Server Now that we’ve covered the key concepts and building blocks, you can see everything in action in the event-based server I’ve implemented. This server handles heartbeat requests and is fully configurable — you can enable or disable features like inline completions or socket pooling using the corresponding option values. event-based server inline completions socket pooling To get started, clone the repository and run the server using the following command: repository repository cd src dotnet run -c Release --InlineCompletions false --SocketPolling false cd src dotnet run -c Release --InlineCompletions false --SocketPolling false Once you run the server, you should see the following output in your terminal, indicating that it’s ready for action: Server started ServerOptions: Port=9096, Address=0.0.0.0, MaxRequestSizeInByte=512, InlineCompletions=False, SocketPolling=False Server started ServerOptions: Port=9096, Address=0.0.0.0, MaxRequestSizeInByte=512, InlineCompletions=False, SocketPolling=False At this point, the server is live, and you’re ready to run your benchmarks to test its performance! Benchmarking the TCP Server To ensure our TCP server performs well, we need to measure its throughput and latency. We’ll compare its performance against a baseline, the same Heartbeat server built using .NET Kestrel . Kestrel is highly optimised in the .NET ecosystem, and while our server is purpose-built, this comparison helps us verify that we’re using sockets efficiently. .NET Kestrel For benchmarking, we used Bombardier , a widely used fast HTTP benchmarking tool also employed by the .NET team in the Crank project to measure Kestrel’s performance. Bombardier Bombardier Bombardier Crank Crank To establish the baseline, I created a simple ASP.NET application exposing a minimal endpoint for handling heartbeat messages. Our tests will make HTTP requests to both the heartbeat server and the baseline Kestrel server. Since IoT devices establish new TCP connections for each heartbeat, we need to simulate this behavior by ensuring each test request creates a new TCP client connection. Unlike Kestrel, which supports connection reuse ( keep-alive ), our server closes the connection after every request. keep-alive Here’s the command we used to run the benchmark: ~$ bombardier -c 32 -m PUT -H "Device-Id:1234" --http1 -a 127.0.0.1:9096 Bombarding http://127.0.0.1:9096 for 10s using 32 connection(s) [==================================================================================================================] 10s Done! Statistics Avg Stdev Max Reqs/sec 10114.69 1085.95 12151.48 Latency 3.13ms 0.96ms 20.28ms HTTP codes: 1xx - 0, 2xx - 101093, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 1.84MB/s ~$ bombardier -c 32 -m PUT -H "Device-Id:1234" --http1 -a 127.0.0.1:9096 Bombarding http://127.0.0.1:9096 for 10s using 32 connection(s) [==================================================================================================================] 10s Done! Statistics Avg Stdev Max Reqs/sec 10114.69 1085.95 12151.48 Latency 3.13ms 0.96ms 20.28ms HTTP codes: 1xx - 0, 2xx - 101093, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 1.84MB/s While the default output is shown above, in our actual benchmarking, we used JSON output for easier parsing and charting. Benchmark Results The benchmark was run 35 times, with the first 5 iterations discarded as warm-up. We tested with varying numbers of connections: 1, 16, 32, 128, and 256 concurrent connections. In all scenarios, the custom heartbeat server outperformed the baseline Kestrel server, both in terms of latency and throughput (requests per minute). This demonstrates that our event-based server, despite being purpose-built, handles high connection loads more efficiently than the baseline, proving that our socket implementation is well-optimised. latency throughput The following chart provides a comprehensive overview of the results: Wrap Up In this post, we demonstrate the process of building a high-performance TCP server using .NET’s Socket class to handle heartbeat messages from IoT devices. We take a deep dive into socket handling, connection management, concurrency models, and efficient I/O techniques like event-driven programming. We explore the custom TCP server with both blocking and non-blocking I/O, along with advanced techniques such as thread pooling and socket multiplexing. Finally, we benchmark the server against the highly-optimised Kestrel server and show how a well-crafted, event-driven architecture can outperform Kestrel in handling high connection loads while maintaining low latency. Next Step: Moving forward, we can further explore the data handling aspect by examining efficient ways to manage and consume buffers. This will allow for more optimised processing of incoming data, enhancing the server’s overall performance.