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.)
Related
I'm making a project in a p2p sharing system which will initiate a lot of sockets with the same ports. right now I'm using a global UdpClient which will use receive and sendasync methods on different threads with different endpoints. there is no usage of mutex as of now which is why I'm asking if collisions are possible using said object if I'm not changing the information inside this object
right now I tried only one example and it doesn't seem to collide although I don't trust one example enough for a full answer
As far as I can see, UdpClient is not thread safe. Thread safe objects should specifically mention that in the documentation, and UdpClient does not seem to do that.
So without any type of synchronization your code is most likely not safe. Testing is not sufficient since multi threading bugs are notorious for being difficult to reproduce. When you write multi threaded code you need to ensure any shared data is synchronized appropriately.
Using it within a lock is probably safe. But that is not a guarantee, UI objects are only safe to use from the thread that created the. Unfortunately that is not always well documented. A problem with locks is that it will block the thread, so locks are best used for very short and fast sections of code, not while doing long running operations like IO. And I don't think the compiler will even let you hold a lock while awaiting.
Another pattern is to use one or more concurrent queues, i.e. threads put messages on the queue, and another thread reads from the queue and sends the messages. There are many possible designs, and the best design will really depend on the specific application. However, designing concurrent systems is difficult, and I would recommend trying to create modules that are fairly independent, so you can understand and test a single module, without having to understand the entire program.
Memory is safe read concurrently. But the same does not extend to objects, since many object may mutate internal state when reading. Some types, like List<T>, specifically mentions that concurrent reads are safe. So make sure you check the documentation before using any object concurrently.
I know what thread safety is. And in some scenarios it makes perfect senses. For instance, I understand that logger need to be thread safe, otherwise it might try to open the same file and access it (when access from multiple threads).
But I cannot visualize, why thread safety is important in while accessing cache. How can get/set from multiple thread can corrupt cache.
And most important, if thread safety is required (while accessing cache), how can we use it when cache is accessed from multiple processes. It would be nice if someone can answer in context of Redis.
Thanks In Advance
Redis is single-threaded. As such all commands in Redis are atomic. However, depending on the implementation in the client library sharing a connection may still be problematic. There would be the potential for reads and writes to be out of sequence such that one thread could get the read another thread was supposed to get causing problems in the client side. This could cause corruption by missing writes or invalid responses causing rewrites.
Thus the concern is not so much corrupting the data in Redis but leaking the data on the client side. Think of a shopping cart with someone else's items being charged to you as an example. For this reason, among others, your client access needs be be thread safe.
Although I have not got any direct text regarding it. But it seems, locking (or other way for synchronization) is applied on server end. And it make sure data is not corrupted from multiple threads/processes.
And why it is important fro make client libraries thread safe, is because they write/read on TCP connection (via network stream I guess). And it is important that if same client is used by multiple thread, it should work fine (in case client is thread safe), otherwise it will be document that, client should not shared among multiple thread.
I am not marking this as a correct answer. If people up vote this and agree on that, then I will do that.
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'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
I am trying to make an app that will pass data between two servers Connection1 and Conenction2 using sockets.What i would like to do is receive data from Connection1 and pass it to Connection2 and vice-versa.Connection1 and Conenction2 are on different threads. What is the best way to call methods on different threads in order to pass data back and forth between them.Both threads will use the same message object type to communicate in both directions between them.
Thanks
You should use immutable data transfer objects.
As long as a simple object is deeply immutable (meaning that neither it nor any of it's properties can change), there is nothing wrong with using it on multiple threads.
To pass the instances between threads, you might want to use a pseudo-mutable thread-safe stack. (This depends on your design)
If .NET 4 is an option, I'd strongly recommend having a look at the ConcurrentQueue<T> and possibly even wrapping it with a BlockingCollection<T> if that suits your needs.
That depends on what those threads are doing. While passing data between threads is relatively straight forward, waking the threads to process the data can be more tricky. When you design communication with a thread per/connection paradigm, your thread is almost all the time stuck in a Read method, like Socket.Receive. While in this state, other threads cannot actually wake this thread to have him send the data they want it sent. One solution is to have the Receive time out every second and check if it has data to transmit, but that just plain sucks.
Another idea is to have 2 threads per socket, one to Send one to Receive. But then all the advantages of having a thread per socket are gone: you are no longer able to have a simple state management of the 'session' in the thread code, you have a state shared between two threads and it's just a mess.
You can consider using async Receive instead: the socket thread posts a BeginReceive then waits on an event. The event is signaled by either the Receive completion or by the send queue having something 'dropped' in (or you can wait on multiple events, same thing basically). Now this would work, but at this moment you have a half-breed, part async part one-thread -per-socket. If you go down this path, I'd go the whole 9 yards: make the server fully async.
Going fully async would be the best solution. Instead of exchanging data between threads, completion routines operate on locked data. The Connection1 BeginReceive completes when it receives data, you parse the received data and analyze the content, then decide to send it on Connection2. So you invoke BeginSend on Connection2's socket, meaning the thread that received the data also send the data. This is much more efficient ans scales better than the thread-per-socket model, but the big disadvantage is that is just plain complicated if you're mot familiar with async and multithreaded programming.
See Asynchronous Server Socket Example and Asynchronous Client Socket Example for a primer.
What you are describing as asynchronous messaging. Microsoft has already written an app for this called MSMQ
I would use WCF on .NET 3.5 for this task, it will be more scalable. I'm using WCF for a lot of my works and its flawless. The good thing about it is you can share your data across any platform.
http://msdn.microsoft.com/en-us/netframework/aa663324.aspx