Member Avatar for kon_t

Hi,

I am interested in comments / experience people have wrt writing a tcp server in .net.

We currently have existing an existing server, written in native c++. It communicates with our own browser client using a proprietery protocol and services hundreds / thousands of concurrent connections. The server uses blocking sockets in multiple threads to obtain reasonable performance.

We have had management requests to move from native code to .net code.

I am fairly confident that we could do the clients in .net.
However, I am unsure about the suitablility of .net for the server. In particular wrt cpu usage.

  • 2 Contributors
  • 1 Reply
  • 116 Views
  • 2 Weeks Discussion Span
  • Latest Post Latest Post by mcldev

Dani AI

Generated

Short answer: yes — managed .NET can host a high‑concurrency TCP server, but only when built with the right I/O and memory model. is right to be cautious about CPU/GC costs; s observation that C# speeds up development is common. The decision should be based on measured prototypes, not just language preference.

Use an event-driven, IOCP-based approach rather than a thread-per-connection design. In modern .NET that means using the asynchronous socket APIs (for example SocketAsyncEventArgs) so the runtime drives overlapped I/O efficiently; see the Microsoft async server examples and the SocketAsyncEventArgs docs for patterns and pitfalls (Asynchronous Server Socket Example, SocketAsyncEventArgs API).

Minimize GC and copies: pre-allocate and reuse receive/send buffers, pool per-connection state objects, and avoid per-request allocations. On newer runtimes ArrayPool<T> and Span<T> drastically reduce allocations; see the ArrayPool<T> docs for safe pooling patterns (ArrayPool<T>).

Profile early and often under realistic load. Measure CPU, GC pauses, and socket latency — a small managed prototype will reveal whether hotspots are parsing, allocations, or CPU-bound logic. Use tools such as PerfView to find GC and CPU hot paths (PerfView). If a prototype shows unacceptable overhead, consider a hybrid approach: managed for control/dispatching with native micro-optimizations for the tightest loops.

Priority checklist: async IO model, buffer/obj pooling, minimal copying, robust error/backpressure handling, and real-load profiling.

Member Avatar for mcldev

.NET for writing TCP servers requires that you use a multi-threaded approach. However this is easy to do so you should be able to achieve good performance on P4 class machines.

At the packet level it depends on whether your PDUs are ASCII or binary. If ASCII the stream functions make it really easy. If binary packets with a routing header, you will need to call the WSock2 functions for network byte order conversion.

To give you an example of performance, I developed a TCP server that takes a stream of PBX events from 1-500 clients (agents). After that a new instance of the Server is required; hence my server also load balances. The avg packet size is 60 bytes, largest is around 300 bytes. My server parses the packets in real-time and dispatches these to Web application clients. In essence, my server is more of a gateway. With that in mind I can tell you the simplicty of C# makes getting the framework of the application a snap.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.