Suppose from the main wpf window (WMain) I create a number of instances of other windows (WA, WB WC ..) all of the same type WModel and each on a seperate thread.
Would the following be a good idea for exchanging information between WMain and WModel?
I am considering to let WMain host a wcf service that can be called from WModel.
And also let WModel host another wcf service that can be called form WMain.
Performance will not be an issue as the communication is limited.
There is no need to use something like WFC if all of the windows are running in the same process.
WCF is for communication between external processes.
If you want to do communication between threads in the same process there are plenty of patterns, starting with something as simple as a threadsafe singleton as a global state container, to using something like a event bus to push events from publishers / subscribers.
Related
Suppose an embedded system which is running different set of softwares which should be communicated together asynchronously, i implemented the data communication mechanism using shared memory ( its fast and simple to use ).
In case of IPC in multiple softwares with different technologies, i was getting into the problem how to notify softwares like a bus mechanism. while there are good IPC/notify mechanism such as unix signal/eventfd/shared semaphores/unix sockets and ..., as i know all of them can be used as point-to-point notification system and i can't find any native solution for bus like notification system.
In BUS notification system, one can notify multiple slaves in single bus notification, rather than creating multiple notification objects for each slave and call notify for all of them.
I know there are already working systems such as D-BUS, but D-BUS is considered too complex for small embedded system and i am looking for native solutions.
Is there any simple, lightweight and native event notification system like D-BUS in linux/unix ?
I found that inotify could be used in such case, but i think is there any
other method exists which was designed for notification propose only?
EDIT:
I think multicast IPC (which was answered here is sightly different from publish/subscribe or BUS.
To be clear, i found that inotify could be used in this situation, suppose on file and multiple file watchers which resembles publish/subscribe IPC pattern, i want to know is there any other solution to this problem?!
I plan to use the PRISM libraries for a project running on a PC that controls one or multiple instruments and visualizes and stores the data of the device(s) and lets the user enter some control data. The devices have various digital and analog sensors and actors. They can be of different type and intelligence. Most often they have no 'real' intelligence and all the control logic sits in the PC.
This 'intelligence' needs to be constantly reading the data from a device. The communication can be of various kind, like a COM port, TCP/IP socket, HTTP to a web interface, etc.
I am not sure what's the best solution for that 'intelligent logic'. Since it needs a continuous communication with the device, it needs to be separated from all the UI tasks. It will need some kind of state-machine in a background worker or thread to build the higher process logic.
Question: Should it be an instance per device registered in PRISM as a service with a reference to that background worker? Or should that background worker be created and linked to the ViewModel I need for each configured instrument to handle it's data to show and edit? Or is there another best solution?
I think this si more general architecture question than a specific PRISM one...
I've done something similar with other MVVM framework and my solution was based on a single listener (I had only TCP sockets to coomunicate with instruments) registerd as a service. In your application you can either have multiple queues or a single queue with multiple producers.
All messages from the devices were inserted in a concurrent queue and each ViewModel (one for each device) read from that queue.
Communication from ViewModel to device happened directly without going through an "output" queue.
The whole application was build on await/async pattern to decouple UI from communication. I was able to send and receive multiple commands and notifications from serval devices at the same time without any issue.
But again this is really a broad question and mine is a broad answer lot of things depend of how you have to interact with dvices. My solution balances complexity with flexibility, but a lot of other architectures are available.
I have an application that began its life as a C#-based Windows GUI that used marshalling to talk to a C DLL.
I now need to separate the Windows client and DLL so that the client is installed on a remote PC and communicates with the C DLL over the internet.
A further complication is that I want to have multiple Windows clients connecting to the C DLL.
This whole world is new to me, so excuse me if the following are naive questions.
My questions:
0) What is the best method for having the client communicate with the DLL over the internet? TCP/IP Sockets?
1) I need to make modifications to my DLL to have it service multiple clients. But I need some piece of middleware that collects the queries from the different clients, feeds them to the DLL, and then sends the results back to the appropriate client. Is there any code (such as node.js) that would facilitate this?
Regarding: What is the best method for having the client communicate with the DLL over the internet?
Your suggestion of using TCP/IP could certainly (and likely will) be part of the solution, but there will be other components of the solution as well. The direction you choose will in part be made by answering whether you are using standard marshaling (COM), or custom? At the very least, your problem description suggests a scenario requiring interprocess communications.
There are many ways to implement. This diagram maps out a general approach, that based on your description might apply:
Components of Interprocess Communications
Read more here
Regarding: make modifications to my DLL to have it service multiple clients...
The dll is simply a file like any other. Several processes can read, and subsequently own content from, a file as long as the processes doing the reading adhere to common file access rules. I do not think you will have to modify your dll, at least for that reason. Just make sure the processes accessing the dll comply with safe file access protocols. (Safe file access).
I am working on a UDP server/client application.
I want my server to be able to handle 40 clients at a time. I have thought of creating 40 threads at server side, each thread handling one client. Clients are distinguished on the basis of IP addresses and there is one thread for each unique IP address.
Whenever a client sends some data to a server, the main thread extracts the IP address of the client and decides which thread will process this specific client. Is there a better way to achieve this functionality?
There are different approaches for scale able server application, one thread per client seems good if no of clients are not many, another most efficient approach to accomplish this task is to use thread pool. These threads are work as task base when ever you have any new task assign this task to free worker thread.
Take a look at this project, I think it is very helpful to start with: http://www.codeproject.com/Articles/16935/A-Chat-Application-Using-Asynchronous-UDP-sockets
With IPAddress.Any, we specify that the server should accept client
requests coming on any interface. To use any particular interface, we
can use IPAddress.Parse (“192.168.1.1”) instead of IPAddress.Any. The
Bind function then bounds the serverSocket to this IP address. The
epSender identifies the clients from where the data is coming.
With BeginReceiveFrom, we start receiving the data that will be sent
by the client. Note that we pass epSender as the last parameter of
BeginReceiveFrom, the AsyncCallback OnReceive gets this object via the
AsyncState property of IAsyncResult, and it then processes the client
requests (login, logout, and send message to the users). Please see
the code attached to understand the implementation of OnReceive.
A better way would be to use the Proactor pattern (take a look at Boost.Asio library), instead of creating thread per client. With such an approach your application would have much better scalability and performace (especially on platforms that have native async i/o)
Besides, with this technique the threading would be de-coupled from the concurrency, meaning that you don't necessarily have to mess with multi-threading with all its complications.
I am new to WPF, and in every tutorial I read, they either have a [System.STAThread] attribute applied to their Main method, or they tell the reader to do that.
Is this attribute really "required"? And if so, why?
This is more a Windows requirement than a WPF one, and goes back to the original design of Windows forms and controls, from before .NET.
STAThread refers to "Single-Threaded Apartments" which refers to the threading model used by the current (main) thread. The threading model in use dictates how other .NET and COM applications will talk to your application (and inherently, its threads). The single-threaded application model requires that no single object "live in" more than one STA thread at a time, verses the MTA thread model; and allows for the passing of pointers to data across apartments only via marshalling-as-object.
Basically, with the [STAThread] declaration, other applications will know what your thread's policy is when sending you data. The STA model is the most common threading model for Windows threads/applications; but you'll sometimes come across certain code that won't run if called from an STA-modeled thread, because it's designed to send/receive data across thread boundaries in ways that don't comply with the STA restrictions. Knowing beforehand what the apartment model of a given thread allows the IDE to catch these exceptions at compile-time instead of getting nasty access violation errors when you attempt to use an object across thread boundaries during runtime.
You can read about STA and MTA threads from the MSDN article at: http://msdn.microsoft.com/en-us/library/ms680112(VS.85).aspx
Note that even normal .NET applications (from before WPF) required the [STAThread] declaration atop of the main().
There's an excellent answer for this in this blog entry.
Quoting from the blog:
When the STAThreadAttribute is
applied, it changes the apartment
state of the current thread to be
single threaded. Without getting into
a huge discussion about COM and
threading, this attribute ensures the
communication mechanism between the
current thread and other threads that
may want to talk to it via COM. When
you're using Windows Forms, depending
on the feature you're using, it may be
using COM interop in order to
communicate with operating system
components. Good examples of this are
the Clipboard and the File Dialogs.
Windows Forms is not supported within
a MTA or free threaded apartment.
Applications using Windows Forms
should always declare the apartment
style they're using, as some other
component could initialize the
apartment state of thread improperly.