4

I am getting a headache with standard socket class of .NET framework.

Could anybody recommend an efficient open source C# sockets (TCP + UDP) library for handling socket messages?

YetAnotherRandomUser
  • 1,320
  • 3
  • 13
  • 31
olidev
  • 20,058
  • 51
  • 133
  • 197
  • 1
    Is there something in particular you're looking for that the CLR sockets don't provide? Or you just want the source code too? – Brook May 05 '11 at 20:51
  • I want source code too. For handling tcp or udp messages thread-based and replying. THanks! – olidev May 05 '11 at 20:52
  • 1
    Whats your headache? What are you trying to do? Normally you would open a socket then you would be responsible for sending whatever messages you wanted. – TedTrippin May 05 '11 at 20:53
  • Hi. it is quite a lot of things. But do you know any library that I mentioned? thanks in advance! – olidev May 05 '11 at 20:56
  • I asked same question here http://stackoverflow.com/questions/5785741/open-source-application-protocol-for-internet-applications as you can see, no answer, except is easy and do it yourself. Still looking for something stable and easy of use. – Eugen May 05 '11 at 21:09
  • I'm sure some good tutorials would go a long way. So far, I've found some from 2001 and 2003 that don't use the modern classes/methods. I hear you about a headache! – YetAnotherRandomUser Feb 13 '18 at 03:07

5 Answers5

6

Use Kerry Jiang's SuperSocket library or Akka.NET

  1. SuperSocket nuget package has over 100k downloads; note that 2.0+ is for .NET Core, whereas 1.6 is for .NET Framework 4.8 and below
  2. SuperSocket.ClientEngine.Core has over 700k downloads
  3. Akka (for .NET) has over 1.2M downloads, and has a special Akka.NET.Test
    • In a sense this is cheating because it postpones the decision of using sockets to the last moment
    • "Akka" started out as a Java/Scala project and was later to .NET
    • Therefore, you should Google search for "Akka.NET" instead of just "Akka"
    • In general, you probably want to construct your Network IO with some solution for back pressure, which you can do with Akka Async Streams in C# 8.
  4. RSocket is a new library built by ex-Netflix engineer Robert Roeser.
    • Similar to Akka Streams in that it provides a way to handle backpressure.

Separately, in terms of using message queuing libraries instead of socket libraries:

  1. EasyNetQ nuget package has over 4M downloads
  2. NetMQ nuget package has over 600k downloads
  3. ZeroMQ nuget package has over 80k downloads
    • I've used this in a real world project and it works fine, but it's a binding wrapper around a C dll
John Zabroski
  • 2,212
  • 2
  • 28
  • 54
3

NetMQ is great for simple socket communication. It handles the reconstruction of messages and much of the messy details. It's meant for message communications as in a messaging system, but it would work great for simple sockets. Take a look at Request-Response. Sockets are one of the areas where you do often end up with framework on top of framework, regardless, let NetMQ handle the nitty gritty.

Michael Silver
  • 483
  • 5
  • 15
0

I made sample application in for console/win app based C# WCF/TCP socket server/client here

https://github.com/evaldsurtans/wcf-sample-server-client

Evalds Urtans
  • 6,436
  • 1
  • 41
  • 31
0

Take a look at WCF which is included in .NET.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
-1

The .NET framework is already a library for handling tcp and udp. It simplifies the process greatly over the base winsock apis. So you want a library that sits on top of the library? Maybe you would then want another library on top of that? And another on top of that one?

My point is, you're likely not going to find anything simpler than what the .net framework already provides. Sockets are a complex topic, and requires that you provide a great deal of implementation yourself.

What a library is often useful for is implementing some already established protocol (like SMTP or FTP), or maybe even giving you more tools to create your own protocol.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • 1
    @Mystere Man Absolutely correct. Compare .Net sockets with your typical WINSOCK program and compare that, even, to low level OSI code, and I think you can see that .Net pretty much makes it easy for socket development. @JoesyXHN socket programming is a very complex topic and not for the weak at heart, there is no silver bullet to make it easier. – SRM May 05 '11 at 21:09
  • Thanks. Would you please recommend me a sample TCP server implementation? and what would you think about this one? http://www.switchonthecode.com/tutorials/csharp-tutorial-simple-threaded-tcp-server Thanks! – olidev May 05 '11 at 21:09
  • @JoesyXHN Thats a good start (the link you provided). Once you understand the basics I suggest taking a look at asynchronous methods. They are key to creating a scalable solution (although you can still get scalability with polling, it's just a lot harder). – SRM May 05 '11 at 21:11
  • could you please tell me where should I add asynchronous methods in that implementation? Thanks! – olidev May 05 '11 at 21:20
  • Any blocking call usually has a BeginXXX EndXXX counterpart. So in the server example you could use BeginListen and EndListen. For reading you can do a BeginRead/EndRead and for sending you can do a BeginSend/EndSend. What it's doing under the wraps is spinning up a thread and using IO completion ports (on NT based systems - all current windows servers are NT based) to determine when the operation is done. Then it calls your asynchronous handler. – SRM May 05 '11 at 21:54
  • Actually, BeginXXX/EndXXX is no longer recommended for sockets. There is a new XXXAsync set of methods that use fewer resources and scale better. – Erik Funkenbusch May 05 '11 at 23:04
  • I do not agree. For instance, check all NIO libraries for java and python. Twisted framework is one example. I would love to have a similar framework for .NET. – jgauffin May 06 '11 at 13:55
  • @jgauffin - As I said, unless you're looking to implement an already well known protocol. Then a library is useful. Twisted is not all that, and has serious performance problems on Windows (which is one reason they're actively looking for help to improve windows performance). There's a difference between a protocol library (which Twisted basically is) and a network library, which just adds more abstraction. – Erik Funkenbusch May 06 '11 at 17:33
  • No. Twisted is a framework which makes it easier to implement protocols. Your or anyone others protocol. That several protocols already is implemented is just a bonus. – jgauffin May 06 '11 at 18:11