I have some legacy code using a CAsyncSocket derived class. This class overrides OnReceive and it also has a wrapper around SendTo. The code is in a dll which multiple applications will be using on the same PC, all ports are hard coded.
I'm guessing that I need to provide synchronization in the form of a named mutex (CMutex in MFC) class bit I'm not sure.
Should I lock a named mutex in the OnReceive and a different named mutex in the Send methods of CMyAsyncSocket?
Do I need synchronization at all or will the MFC CAsyncSocket do that for me? Worried about accessing a socket on multiple processes.
The underlying socket will provide connection isolation so you don't need to worry about protecting each processes connection. Assuming you just have one thread using the socket in each process you just need to handle the blocking issues which can occur with AsyncSocket, ie when the socket is not ready to deal with the request ?
Related
I am trying to turn my app multithreading. What I want to achieve is:
- Receive command via TidHTTPServer
- Execute local action (might involve using tidHTTP to send/receive data to other services)
- return execution result to the original caller
since I am pretty new to multi-threading I would like to know if my design-idea is correct
TMsgHandler=Class(TThread)
in TidHTTPServer.OnCommandGet I create a new instance of TMsgHandler and pass ARequestInfo and AResponseInfo
TMsgHandler.Excecute interprest the data
Can TMsgHandler.Execeute use Objects (descendants of TidHTTP) in my Main to communicate with other services?
TMsgHandler sends answer through AResponseInfo and terminates.
will this work?
This is not the correct design.
THTTPServer is a multi-threaded component. Its OnCommand... events are fired in the context of worker threads that Indy creates for you.
As such, you do not need to derive your TMsgHandler from TThread. Do your TIdHTTP directly in the context of the OnCommand... thread instead. A response will not be sent back to the client until your event handler exits (unless you send one manually). However, you should not share a single TIdHTTP from the main thread (unless you absolute need to, in which case you would need to synchronize access to it). You should create a new TIdHTTP dynamically directly in your OnCommand.../TMsgHandler code as needed.
I am trying to write a server program which supports one client till now and over the few days i was trying to develop it, I concluded i needed threads. The reason for such a decision was since I take input from a wifi socket and later process it and finally write to a file, the processing time is slow and hence i needed a input thread -> circular buffer -> output thread pattern with producer consumer model which is quite common in network programming.
Now, The situation becomes complicated, as I need to manage client disconnection and re connection. I thought of using pthread_exit() and cleaning up all the semaphores and then re initializing them each time the single client re connects.
My question is that is this a efficient approach i.e. everytime killing the threads and semaphores and re creating them. Are there any better solutions.
Thanks.
My question is that is this a efficient approach i.e. everytime killing the threads and semaphores and re creating them. Are there any better solutions.
Learn how to use non-blocking sockets and an event loop. Or use a library that provides TCP sessions for you using non-blocking sockets under the hood. Such as boost::asio.
Learn how to use multi-threading without polluting your code with any synchronization primitives by using message passing to communicate between threads, not shared state. The event loop library you use for non-blocking I/O should also provide means for cross-thread message passing.
Some comments and suggestions.
1-In TCP detecting that the other side has silently disconnected it very difficult if not impossible. A client could disconnect sending a RST TCP message to the server or sending a FIN message, this is the good case. Sometimes the client can disconnect without notice (crash, cable disconnection, etc).
One suggestion here is that you consider the way client and server will communicate. For example, you can use function “select” to set a timeout for receiving a message from client and detect a silent client.
Additionally, depending on the programming language and operating system you may need to handle broken pipe (SIGPIPE) signal (in Linux, with C/C++), for a server trying to send a message through a connection closed by the client.
2-Regarding semaphores, you shouldn’t need to clean semaphores in any especial way when a client disconnect. By applying common good practices of locking and unlocking mutexes should be enough. Also with resources like file descriptors, you need to release them before ending the thread either by returning from the thread start function or with pthread_exit. Maybe I didn’t understand this part of the question.
3-Regarding threads: if you work with multiple threads to optimum is to have a pool of pre-created consumer/worker threads that will check the circular buffer to consume the next available connection. Creating and destroying threads is costly for the operating system.
Threads are resource consuming and you may exhaust operating system resources if you need to create 1,000 threads for example.
Another alternative, is to have only one consumer thread that manages all connections (sockets) asynchronously: a) Each connection has its own state. b) The main thread goes through all connections and use function “select” to detect when connection reads or a writes are ready. 3)Use of non-blocking sockets but this is not essential because from select you know which sockets are ready and will not block.
You can use functions select, poll, epoll.
One link about select and non-blocking sockets: Using select() for non-blocking sockets
Other link with an example: http://linux.die.net/man/2/select
I know it is forbidden in the OpenSSL API to call SSL_read and SSL_write from two different threads on the same SSL context, but it's important in my application to have secure full-duplex communication. I thought of some solutions, none of which I really like:
Use two SSL contexts per connection. I don't like this because it uses more resources, and it would complicate my implementation. However, I would be fine using this if I could just "duplicate" an existing SSL context rather than creating a whole new connection from scratch.
Use non-blocking sockets with a mutex controlling access to an SSL context. This would require resource-hogging polling, and I heard the non-blocking implementation is just not very good.
This seems like it would be a rather common thing to do, so what is an accepted solution to this problem?
Use non-blocking sockets with a mutex controlling access to an SSL context.
With non-blocking sockets inside a single thread you would not need mutexes, because you only either read or write (because of single thread).
This would require resource-hogging polling, ...
You would not need "resource-hogging" polling. I assume you mean here busy polling instead of using the usual facilities of the system (like select) to wait (not loop) until data are available or data can be send. But contrary to read/write on plain sockets, SSL sockets can need a read if they want to write and a write if they want to read and they might have data inside even if the socket is not readable. Look out for SSL_WANT_READ, SSL_WANT_WRITE and SSL_pending.
...and I heard the non-blocking implementation is just not very good.
It looks more complex if you are used to using threads. But did you ever wonder why high performance servers like nginx don't use threads but non-blocking I/O? That is because it needs less resources and has not the problems associated with threads, like needing to mutex your way around critical sections (overhead) and getting strange and sporadic errors when forgetting to mutex something. nginx also uses openssl with non-blocking I/O.
I personally use non-blocking I/O all the time and while it is harder to do correctly with SSL because of the protocol itself and not the OpenSSL implementation it is doable and fast.
This means, that non-blocking I/O within a single thread is a way you could go to solve your problem. The other way would be to let SSL only work with memory BIOs instead of real file descriptors and do all the reading and writing yourself. But this is probably even more complex than non-blocking I/O.
BTW, usually SSL context means the SSL_CTX object which can be shared between multiple SSL connections and which has probably no problems with multiple threads. What you mean is that the same SSL connection (the SSL object) should not be used from multiple threads.
I'm building a multi-threaded service application in Delphi XE2. Each thread serves its own purpose apart from the other ones. The main service thread is only responsible for keeping the other threads going and saving a log file, etc. Each of these threads reports back to the main service thread through synchronized event triggers. These threads are created when the service starts and destroyed when the service ends.
I'd like to introduce a separate thread as a centralized database connection to avoid having to create many instances of TADOConnection. My service code can call standard functions such as UserListDataSet := DBThread.GetUserList(SomeUserListDataSet); or it would also be nice if I could send direct SQL statements like SomeDataSet := DBThread.Get(MySqlText);. I'd also like to avoid too many occasions of CoInitialize() etc.
The job threads will need to use this db thread. I need to figure out how to "ask" it for certain data, "wait" for a response, and "acquire" that response back in the thread which requested it. I'm sure there are many approaches to this, but I need to know which one is best suited for my scenario. Windows messages? Events? Should I have some sort of queue? Should it send data sets or something else? Is there already something that can do this? I need to figure out how to structure this DB thread in a way that it can be re-used from other threads.
The structure looks like this:
+ SvcThread
+ DBThread
+ TADOConnection
+ Thread1
+ Thread2
+ Thread3
I need threads 1 2 and 3 to send requests to the DBThread. When a thread sends any request to it, it needs to wait until it gets a response. Once there's a response, the DB Thread needs to notify the asking thread. Each of the threads might send a request to this DB Thread at the same time too.
A good tutorial on how to accomplish this would be perfect - it just needs to be a suitable fit for my scenario. I don't need to know just "how to make two threads talk together" but rather "how to make many threads talk to a centralized database thread". These job threads are created as children of the main service thread, and are not owned by the db thread. The db thread has no knowledge of the job threads.
Normally, you'd have a request queue where all the requests are stored. Your database thread reads a request from the queue, handles it, then invokes a callback routine specified by the requester to handle the result. Not sure how this maps to Delphi paradigms, but the basics should be the same.
Do any of the "requesting" threads have anything profitable that they could be doing while they are waiting for a response to be obtained from the database? If the answer is "no," as I suspect that it is quite likely to be, then perhaps you can simplify your situation quite a bit by eliminating the need for "a DB thread" completely. Perhaps all of the threads can simply share a single database-connection in turn, employing a mutual-exclusion object to cause them to "wait their turn."
Under this scenario, there would be one database-connection, and any thread which needed to use it would do so. But they would be obliged to obtain a mutex object first, hold on to the mutex during the time they were doing database queries, and then release the mutex so that the next thread could have its turn.
If you decide that it is somehow advantageous (or a necessity...) to dedicate a thread to managing the connection, then perhaps you could achieve the result using (a) a mutex to serialize the requests, as before; and (b) one event-object to signal the DB-thread that a new request has been posted, and (c) another event-object to signal the requester that the request has been completed.
In either case, if you have indeed determined that the requester threads have nothing useful that they could be doing in the meantime, you have the threads "simply sleeping" until their turn comes up. Then, they do their business, either directly or indirectly. There are no "queues," no complicated shared data-structures, simply because you have (say...) determined that there is no need for them.
I think using a DB connection pool would be a better fit for your problem. This would also allow you to scale your application later on without having to then create additional DB thread and then having to manage "load balancing" for those DB threads.
Since you are mentioning using TADOConnection please have a look at this implementation made by Cary Jensen http://cc.embarcadero.com/item/19975.
I am successfully using this DB connection pool in several applications. I have modified it in several ways, including using an ini file to control: maximum number of connections, cleanup time, timeout times etc.
Cary has written several articles that serves as documentation for it. One is here http://edn.embarcadero.com/article/30027.
From https://developer.mozilla.org/En/Gecko_Plugin_API_Reference:Scripting_plugins :
This API is not designed to be thread safe. The threading model for this API is such that all calls through this API are synchronous and calls from a plugin to methods in this API must come from the thread on which the plugin was initiated, and likewise all calls to methods in this API by the browser are guaranteed to come from the same thread. Future revisions to this API might provide a mechanism for proxying calls from one thread to another to aid in using this API from other threads.
If I want to access a global variable in my plugin (shared between all instances, even on different pages), do I need to lock it or does the browser use only one thread to communicate with the plugin for all instances?
The browser always uses exactly one thread to communicate with the plugin for all instances; you should do the same in return and never call any NPN_ functions from other than the main thread.
Keep in mind that if you're doing anything that may block the main thread at all you'll want to create your own threads and in that case you may need locking; however, just for the browser? no, you don't need them.