2

Back in the day, VB6 had the Winsock.ocx control, which provided dead simple access to UDP and TCP communications. It exposed events which fired when data was received, and the interface was extremely simple and straightforward to use. You could build a TCP client/server app or UDP communication app in minutes.

Fast forward to VB.NET and all we seem to have are the System.Net.Sockets libraries like UdpClient, which are extremely convoluted to use. They either require the use of Tasks or Threads, or the Receive() call blocks until data arrives, freezing the entire UI until a message is received.

To me this seems like a backward step, but maybe I'm missing something.

Is there an alternative library/plugin which provides:

  1. Events which fire when data is received etc.
  2. No need to deal with threads or tasks
  3. Does not block and can be used in a WinForms app
  4. Simple way to send/receive arbitrary data via UDP or TCP connections?
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Ryan Griggs
  • 2,457
  • 2
  • 35
  • 58
  • 1
    _"Back in the day, VB6 had the Winsock.ocx control.....Fast forward to VB.net...have ...`UdpClient`, which are `extremely convoluted` to use. They either `require` the use of `Tasks or Threads` or the Receive call blocks until data arrives, `freezing the entire UI`"_ - VB6 was magically non-blocking? –  Nov 08 '19 at 04:50
  • _"..UdpClient, which are extremely convoluted to use. They either require the use of Tasks or `Threads`..."_ - if you mean you need to explicity spin up a thread yourself to receive that is **incorrect**. The old-style `BeginReceive` merely sets up an asynchonous callback (not to be confused with either `async` or threads). https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.udpclient.beginreceive?view=netframework-4.8#System_Net_Sockets_UdpClient_BeginReceive_System_AsyncCallback_System_Object_ –  Nov 08 '19 at 04:54
  • @MickyD I was simply trying to provide some context for *why* I wanted a VB6 winsock equivalent. Otherwise everyone is just like "use System.Net.Sockets and follow the examples in the documentation." – Ryan Griggs Nov 08 '19 at 05:29
  • @MickyD No I didn't say VB6 was non-blocking. It just encapsulated the entire process, making it easy for the programmer to get a TCP or UDP connection going in just a few lines of code. – Ryan Griggs Nov 08 '19 at 05:29
  • I've actually written a class that seems to meet most of your requirements. It _does_ use a thread internally, but you don't have to do so yourself. Please see this answer of mine: [TCP Client to Server communication](https://stackoverflow.com/a/35240061/3740093) – Visual Vincent Nov 08 '19 at 05:37
  • 1
    Why didn't anyone mention BackgroundWorkers? I just discovered this object a minute ago when researching Thread-Safe UI interaction and it made the whole process much simpler. I can now send/receive UDP messages asynchronously and interact with the UI thread with very little difficulty. Is it unsafe to use BackgroundWorkers? See this article if you're interested: https://learn.microsoft.com/en-us/dotnet/framework/winforms/controls/how-to-make-thread-safe-calls-to-windows-forms-controls?redirectedfrom=MSDN – Ryan Griggs Nov 08 '19 at 06:41
  • 3
    @RyanGriggs Because `BackgroundWorker` is outdated and replaced by `Task` since .NET 4.0. Here's a series talking about it: https://blog.stephencleary.com/2013/05/taskrun-vs-backgroundworker-intro.html *"BackgroundWorker really is dead at this point and should not be used for new development"* -- and that was in 2013! – Herohtar Nov 08 '19 at 06:50
  • @Herohtar OK forgive me for sounding stupid, but how are async tasks supposed to communicate with the main UI task? What am I missing here??? – Ryan Griggs Nov 08 '19 at 07:05
  • You can use [`Progress`](https://learn.microsoft.com/en-us/dotnet/api/system.progress-1); there is a simple example in [part 5](https://blog.stephencleary.com/2013/09/taskrun-vs-backgroundworker-round-5.html) of the series I linked. You can also run any arbitrary code on the UI thread by using [`Dispatcher.Invoke`](https://learn.microsoft.com/en-us/dotnet/api/system.windows.threading.dispatcher.invoke?view=netframework-4.8) – Herohtar Nov 08 '19 at 07:29

1 Answers1

0

There is not built-in control like Winsock in .net. Essentially you need to use the System.Net.Sockets members like TcpClient or UdpClient to do all the stuff. There are examples of how to use this namespace to take care of socket programming scenarios in .net.

TcpClient
https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.tcpclient?view=netframework-4.8

UdpClient
https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.udpclient?view=netframework-4.8

and I advise checking the rest of the examples in this area like how to use listeners and so on.

Siavash Rostami
  • 1,883
  • 4
  • 17
  • 31
  • I'm aware of the examples and have tried several. I keep running into issues with Tasks and blocking and I'm not sure how to *properly* pass data from the asynchronous listening process back to my UI process. The examples seem to be focused on console apps which don't care if the entire process blocks while awaiting a reply. – Ryan Griggs Nov 08 '19 at 05:32
  • 1
    When it comes to sensitive areas like socket programming, you have to have a solid grasp of TPL and .Net fundamentals. Without that using examples blindly is a huge risk. The thing is this concept is not as simple as you're expecting it to be. I mean once you learn the gist of these examples you can apply them to any application be it console or Winforms or WPF. – Siavash Rostami Nov 08 '19 at 08:49
  • That's exactly my point. Something that was trivial in VB6 now takes more time and work to implement than all the other parts of the application combined. – Ryan Griggs Nov 08 '19 at 14:54