README.md (3768B)
1 # NetSharp 2 3 A networking library written in C#, focusing on performance and built on top of SocketAsyncEventArgs. 4 5 It is geared towards asynchronous and highly concurrent applications, which aim for maximum bandwidth. 6 7 For help with the library, feel free to visit our Discord and ask any questions [here](https://discord.gg/DKQhxuY). 8 9 | Service | Status Badge | 10 | ------- | ------------ | 11 | Discord | [![Discord Server][discord-server-badge]](https://discord.gg/DKQhxuY) | 12 | Code Quality | [](https://www.codefactor.io/repository/github/mblenczewski/netsharp/overview/master) | 13 14 ## Examples & Benchmarks (WARNING: STALE) 15 #### NOTE: I'll redo these when i have time, im currently reimplementing the library due to some issues i encountered. They are still up here because i want to know what i need to beat performance-wise, and what benchmarks i included 16 17 The library comes with a .NET Core 3.1 console project containing examples and benchmarks for the components of the library. The example project and a few benchmarks can be seen below: 18 19 ### Example Project 20 21 ![Example Project 'Main Menu'][example-project] 22 23 ### Benchmarks 24 25 #### Preface 26 27 All the benchmarks were performed on a Ryzen 7 1700 CPU @ 3.20GHz. This library is built to be concurrent and to scale well with the number of execution threads available. The per-core clocks are also important though (when are they not?). 28 29 During a benchmark 1,000,000 packets are sent per client by default, with a data segment size of 8192 bytes (8 kibibytes). This means that, by default, 8.192 gigabytes of user data are sent one way, and 8.192 are received (in the form of a response packet). The server is set up to simply echo any received packets, so packet processing overhead is virtually non-existent. Your mileage may vary. 30 31 The RTT values measured are the very extremes of what you would get. When printing the RTT-per-packet, the maximum value is attained at the start of the connection and the minimum value seems to be sustained for the remainder of the connection. Again, your mileage may vary depending on the speed of your network, your packet loss (if using TCP), and the amount of packet processing you do on the server. The more processing you do, the longer your RTT times will be. 32 33 ### Datagram Network Reader & Writer Benchmarks 34 35 The following is the datagram network listener (UDP) benchmark: 36 37 ![Datagram Network Reader Benchmark][datagram-network-reader-benchmark] 38 39 The following are the synchronous and asynchronous datagram network writer (UDP) benchmarks. Worse performance is expected when compared to the synchronous benchmark, due to the increased overhead of async operations: 40 41 ![Datagram Network Writer Benchmark][datagram-network-writer-benchmark] 42 43 ### Stream Network Reader & Writer Benchmarks 44 45 The following is the stream network listener (TCP) benchmark: 46 47 ![Stream Network Reader Benchmark][stream-network-reader-benchmark] 48 49 The following are the synchronous and asynchronous stream network writer (TCP) benchmarks. Worse performance is expected when compared to the synchronous benchmark, due to the increased overhead of async operations: 50 51 ![Stream Network Writer Benchmark][stream-network-writer-benchmark] 52 53 [discord-server-badge]: https://img.shields.io/discord/703255900600795196.svg?style=flat-square&logo=discord&color=blue 54 55 [example-project]: docs/example-selector.png 56 57 [datagram-network-reader-benchmark]: docs/datagram-network-reader-benchmark.png 58 [datagram-network-writer-benchmark]: docs/datagram-network-writer-benchmark.png 59 60 [stream-network-reader-benchmark]: docs/stream-network-reader-benchmark.png 61 [stream-network-writer-benchmark]: docs/stream-network-writer-benchmark.png 62