I've read much on TcpClient and multithreading at stackoverflow but think I didn't find a clear answer to this.
I have an application with 3 identical threads.
(calling the same method on each thread object)
Every thread creates his own (local) TcpClient instance and opens a tcp connection to his server (different IP addresses).
The threads are supposed to do the same things only on a different server.
The 3 server machines are running identical server software.
Now the 3 threads start a server request 'at the same time'.
Are the TcpClient objects totally isolated on each thread ?
Or may it be that the underlying streams are unwillingly shared ?
I got the feeling that sometimes a thread gets data that's not from 'his' server.
For examlpe all threads are polling for a 'ready' flag.
Only Server 1 is ready and sets the flag, but thread 1 AND thread 2 see the flag set.
There's a good chance that I'm doing things wrong.
But it would help to surely know that communication on the TcpClient objects in this way is safe.
Thanks a lot for any suggestions,
Ralf
PS: And yes, I am currently reading books and documentation on multithreading in C# 8-))
If the TcpClient instances are separate, then they won't be sharing any state - you can use as many TcpClient instances as you need. If data is leeching between threads, I can only assume that it is in your own code. A common cause of confusion here is captured variables (anything from a lambda / anon-method), which prior to C# 5 can be shared in ways that the casual reviewer might not anticipate. Without more info we can't say more, but no: they should not interfere with each-other.
Could be a problem with the port to which a server send the response back. Afaik the source port is determinatet automaticily depending on the programm which sends a request to a server. Perhaps the port determination does not differ between each threat, so the three simultaneous running threats recive an answer on the same port... but thats only my guess I am not very into TCP-stuff
Related
I need to reimplement a database connection driver for some legacy cobol database for one of my customers. The way the application is built, i cannot use async/await (just leave it like that, i know it is stupid).
The whole application is an ASP.NET API.
The old driver uses a c++ dll, that is included with inter-op methods. The idea behind the old system is: use one connection to the db for everything, have multiple threads send a packet and have one thread that receives the answers and delegates them to the right thread.
To keep the connection alive, one needs to send some sort of ping message to database and handle its pong message.
I reimplemented that as POC in c#, have one connection, open a background thread and use AutoResetEvents to notify the right threads that the answer is ready to be processed. I set the ReceiveTimeout to 5 seconds, and while there was nobody sending data to the server, the receive timeout helped me to send the ping-message to the server.
A reason for the rewrite is, that the one-connection-solution does not scale.
So, my idea is to use a socket pool and ReceiveAsync with SocketAsyncEventArgs on the sockets.
The solution works so far, but not really good. Here are some questions:
As ReceiveTimeout is not compatible with ReceiveAsync, is there a other way then a timer to send my ping-messages
when using ReceiveAsync, can i still use normal Send to send data, or do i have to use SendAsync?
when ReceiveAsync does not receive all required data, may i use Receive to read the rest of it, or is it better to use ReceiveAsync again for the missing data?
Maybe not relevant: I use Artillery to fire some performance tests on the new driver; from time to time they timeout after 30 seconds (thats the db-transaction timeout i set); when i try to debug that Artillery gets ESOCKETTIMEDOUT even though no breakpoint is hit - is this a known behaviour when debugging an IIS process under load?
use AutoResetEvents to notify the right threads that the answer is ready to be processed.
May I suggest a thread-safe queue? BlockingCollection<T> or BufferBlock<T>?
I set the ReceiveTimeout to 5 seconds, and while there was nobody sending data to the server, the receive timeout helped me to send the ping-message to the server.
This is weird. I assume the entire protocol is ping-pong based, or else using a receive timeout to send messages would not work.
my idea is to use a socket pool and ReceiveAsync with SocketAsyncEventArgs on the sockets
If you can't use async/await, I would advise switching to the Begin*/End* style of asynchronous API. Going straight from synchronous to SocketAsyncEventArgs is quite a leap; SocketAsyncEventArgs is the most difficult form of socket async programming.
is there a other way then a timer to send my ping-messages
I would recommend a timer; that's the normal solution for heartbeat messages. The desired semantics should be "we want to send data at least this often". So use a timer that you can reset when sending regular messages (not receiving messages).
when using ReceiveAsync, can i still use normal Send to send data, or do i have to use SendAsync?
You should be able to use synchronous for one stream and asynchronous for the other. I've never tried this, though; all systems I've worked on are fully asynchronous.
when ReceiveAsync does not receive all required data, may i use Receive to read the rest of it, or is it better to use ReceiveAsync again for the missing data?
This question doesn't make as much sense to me. If you're asynchronously reading, you shouldn't block the calling thread.
Also, I think this question is framed from the wrong perspective. It seems like the code wants to "receive the next message", but this is a problematic way to approach reading from a socket. Instead, I recommend that your code have a loop that endlessly reads from the socket and passes that data to another type that buffers it as necessary and pushes out messages as they finish.
is this a known behaviour when debugging an IIS process under load?
I would not expect so, but I don't have much IIS load testing experience.
I'm trying to build this server that receives connections on a socket, authenticates the user and then "sends" the socket to the class of the user that matches it(with the info given in the authentication), to be added to a thread pool (of the multiple devices of that client) to be processed (exchanging information, updating things elsewhere, etc..).
I chose to do it this way because I don't want to be sending requests to the server 24/7, just keep a lightweight thread open for each device, communicating with it in real time.
Now, all I've seen so far that might do something like this is Socket.DuplicateAndClose, but that works for processes, not threads.
So is anyone aware of any way to do this, or should I take a different approach?
Thank you.
EDIT:
It seemed that there was some confusion, what I meant was, move it to another Socket inside another class, then the threads open on that class will process it. If I accept the connection to authenticate it, that socket then is having that connection, beforehand I couldn't have known to accept it with the specific socket in the specific class because I didn't know where it came from, and now, I have a thread I can't do anything with because I can't tell that class to use this thread, because if I do and use it in a thread of that class, the next socket I use to accept the connection will be the one that's occupied by that same class. I could use a huge array to store accepted sockets and tell classes that that socket number was theirs, but that would not only be limited but a bunch of loose sockets as well, which would work but would be neither optimized or organized.
There is no restriction on which threads access a given socket.
Any thread can perform operations on any socket (providing the thread's process has an open handle to that thread).
Performing multiple IO operations of the same type (eg. two reads) concurrently on one socket is likely to lead to confusion – you cannot control which will get the next data, and it could then complete second. But any form of explicit or implicit concurrence control can be used to avoid that.
(The same applies to other kernel objects like files, named pipes, shared memory sections, semaphores, …. The only thing that is restricted is only the thread holding a mutex or critical section can release it.)
I have a C# application which listens for incoming TCP connections and receive data from previously accepted connections. Please help me whether i use Threadpool or Async methods to write the program?? Note that, once a connection is accepted, it doesn't close it and continuously receive data from the connection, at the same time it accept more connections
A threadpool thread works best when the code takes less than half a second and does not a lot of I/O that will block the thread. Which is exactly the opposite scenario you describe.
Using Socket.BeginReceive() is strongly indicated here. Highly optimized at both the operating level and the framework, your program uses a single thread to wait for all pending reads to complete. Scaling to handle thousands of active connections is quite feasible.
Writing asynchronous code cleanly can be quite difficult, variables that you'd normally make local variables in a method that runs on the threadpool thread turn into fields of a class. You need a state machine to keep track of the connection state. You'll greatly benefit from the async/await support available in C# version 5 which allows you to turn those state variables back into local variables. The little wrappers you find in this answer or this blog post will help a great deal.
It mainly depends on what do you want to do with your connections. If you have unknown number of connections which you don't know how long they will be open, I think it's better to do it with async calls.
But if you at least know the avg. number of connection and the connections are short-term connections like a web server's connections, then it's better to do it with threadpool since you won't waste time creating threads for each socket.
First off, if you possibly can, don't use TCP/IP. I recommend you self-host WebAPI and/or SignalR instead. But if you do decide to use TCP/IP...
You should always use asynchronous APIs for sockets. Ideally, you want to be constantly reading from the socket and periodically writing (keepalive messages, if nothing else). What you don't want to do is to have time where you're only reading (e.g., waiting for the next message), or time where you're only writing (e.g., sending a message). When you're reading, you should be periodically writing; and when you're writing, you should be continuously reading.
This helps you detect half-open connections, and also avoids deadlocks.
You may find my TCP/IP .NET Sockets FAQ helpful.
Definately use asynchronous sockets... It's never a good idea to block a thread waiting for IO.
If you decide you have high performance needs, you should consider using the EAP design pattern for your sockets.
This will allow you to create an asynchronous solution with a lower memory profile. However, some find that using events with sockets is awkard and a bit clunky... if you fall into this category, you could take a look at this blog post to use .NET 4.5's async/await keywords with it: http://blogs.msdn.com/b/pfxteam/archive/2011/12/15/10248293.aspx#comments
I'm doing an application in C#, with a server and some clients (not more than 60), and I would like to be able to deal with each client independently. The communication between server and client is simple but I have to wait for some ack's and I don't want to block any query.
So far, I've done two versions of the server side, one it's based on this:
http://aviadezra.blogspot.com.es/2008/07/code-sample-net-sockets-multiple.html
and in the other one, I basically create a new thread for each client. Both versions work fine...but I would like to know pros and cons of the two methods.
Any programming pattern to follow in this sort of situation?
To answer your question it's both. You have threads and classes running in those threads. Whether you use WCF, async, sockets, or whatever, you will be running some object in a thread (or shuffled around a threadpool like with async). With WCF you can configure the concurrency model, and if you have to wait for ack's or other acknowledgement you'd be best to set it to multiple threads so you don't block other requests.
In the example you linked to the author is using AsyncCallback as the mechanism for telling you that a socket has data. But, from the MSDN you can see:
Use an AsyncCallback delegate to process the results of an asynchronous operation in a separate thread
So it's really no different for small scale apps. Using async like this can help you avoid allocating stack space for each thread, if you were to do a large application this would matter. But for a small app I think it just adds complexity. C# 4.5+ and F# do a cleaner job with async, so if you can use something like that then maybe go for it.
Doing it the way you have, you have a single thread that is responsible for socket management. It'll sit and accept new connections. When it gets a request it hands that socket to a new dedicated thread that will then sit on that socket and read from it. This thread is your client connection. I like to encapsulate the socket client reading into a base class that can do the low level io required and then act as a router for requests. I.e. when I get request XYZ I'll do request ABC. You can even have it dispatch events and subscribe to those events elsewhere (like in the async example). Now you've decoupled your client logic from your socket reading logic.
If you do things with WCF you don't need sockets and all that extra handling, but you should still be aware that calls are multi-threaded and properly synchronize your application when applicable.
For 60 clients I think you should choose whatever works best for you. WCF is easy to set up and easy to work with, I'd use that, but sockets are fine too. If you are concerned about the number of threads running, don't be. While it's bad to have too many threads running, most of your threads will actually be blocked while they are waiting on IO. Threads that are in a wait state aren't scheduled by the OS and don't really matter. Not to mention the waiting is most likely is using io completion ports under the hood so the wait overhead is pretty much negligible for a small application like yours.
In the end, I'd go with whatever is easiest to write, maintain, and extend.
I have just learned that you can use a Thread pool for multi client TCP-connections, I have an C# application today that I like to implement this to. I have read some, for example the first answer to this question ( Best way to accept multiple tcp clients? ), but I dont really get how to make the last adjustments to work with my "needs". I have a messagehandeling function for each connection (each connection is 2 threads, one for recieving/sending messages (connection open for a long duration moste of the time) and one for doing Tasks depending on the messages (also creates answers to send back). I would now like to use the recieving method in the link below, but how can I do this with a thread pool in my example?
If anything is unclear, just ask questions!
/Nick
Just avoid having one thread per connection. It generate lot of overhead on the OS and doesn't scale well.
Today we use NIO : non blocking I/O. One thread can handle 10k+ connections. There are very easy way to use them, like NodeJs for example. NIO libraries are available for most platform/languages (Netty for Java, NodeJs with javascript,...).
You should specify wich language/environement you are using.