[2.0] Multithreaded TCPClient example?

[Pc_Madness]

SIGH! Alright, heres what I want to do. And after 5 attempts at writing this post, its alot harder to explain than I thought.

Basically, I'm doing a Peer to Peer program. Atm I have it so that all of the peers can find each other using a Backgroundworker and a blocking UDPClient (which should work fine?).

Now, I want computers to be able to connect to send me data over TCP. Does someone have an example of this that will work well with a GUI. I need to be able to pass data between the GUI thread and the TCPClient/Socket thread, and it has to be able to support multiple connections.

Can anyone direct me towards such an example? Winsock in VB6 has corrupted me it seems. It doesn't have to be TCPClient it can be Sockets or whatever other options there are. I've looked at so many examples on Google and they all have their faults for one reason or another.

[jmcilhinney]

Have you read the documentation for the TcpListener class? Have you read the documentation for its BeginAcceptTcpClient method? It's the asynchronous equivalent to AcceptTcpClient. The MSDN documentation has a code example. You'd just call the method and then each time you receive a connection request you'd accept it and call the method again, to wait for the next one.

There's a BeginAcceptSocket method too.

[Pc_Madness]

Have you read the documentation for the TcpListener class? Have you read the documentation for its BeginAcceptTcpClient method? It's the asynchronous equivalent to AcceptTcpClient. The MSDN documentation has a code example. You'd just call the method and then each time you receive a connection request you'd accept it and call the method again, to wait for the next one.

There's a BeginAcceptSocket method too.

Thats really not all that helpful.

How do I invoke 'DoBeginAcceptTcpClient' since it already assumes I have a TCPListener?
What is the 'tcpClientConnected' event for?
You said you call the method again, are you saying 'DoAcceptTcpClientCallback' should be calling '..AcceptClient' in a loop?
Where do I go after I've called the ClientCallBack function?
Should the above functions be called from inside a seperate thread?

As I said, a link to an example is what I'm after so that I can see how it all works together, not a lecture.

[jmcilhinney]

It is helpful if you'd care to read it and research what it's telling you.

How do I invoke 'DoBeginAcceptTcpClient' since it already assumes I have a TCPListener?v

If you're listening for TCP connections then presumably you do already have a TcpListener. You don't invoke the DoBeginAcceptTcpClient method. It's invoked via the delegate when a connection request is received.

How do I invoke 'DoBeginAcceptTcpClient' since it already assumes I have a TCPListener?

Wherever the tcpClientConnected variable is used there's a comment that tells you what it's doing. If you want to know more then read the documentation for the ManualResetEvent class.

You said you call the method again, are you saying 'DoAcceptTcpClientCallback' should be calling '..AcceptClient' in a loop?

Why would you use a loop? I said when you receive a connection you accept it and call the method again, so after you call EndAcceptTcpClient you call DoBeginAcceptTcpClient again.

Should the above functions be called from inside a seperate thread?

The whole point of this asynchronous model is so you don't have to explicitly create threads. You call the Begin method, internally it creates a new thread that does the work and the Begin method returns. You can then get on with your life. When the background thread finishes its work, which in this case means receives a connection request, it signals your app by invoking the delegate that you provided when you called Begin. You then call the corresponding End function and you get the result. Calling BeginAcceptTcpClient and EndAcceptTcpClient has the same net result as calling AcceptTcpClient except that you can do stuff while you're waiting for a connection rather than blocking.

The TcpListener.BeginAcceptTcpClient method documentation says this:

For detailed information about using the asynchronous programming model, see Calling Synchronous Methods Asynchronously.

and provides a link. Did you follow that link?

That MSDN topic provided enough for you to learn the rest for yourself by researching the appropriate topics. If you choose not to do that research, but rather wait for someone to provide you a pre-baked solution then that's your prerogative, but your choosing to ignore information does not make it unhelpful.