What is the best way to send a byte stream from one Windows process to another assuming that both processes are running as a Windows service? The data consists of an image buffer. Each service is running on a separate server on the same subnet.
Should the second service that is receiving the buffer be a web service (as opposed to a Windows service), even though it will never be called on a website (just internally)?
Is RPC the best method of communicating data between two windows services? There will be a lot of data passed and performance is key.
Development language is C# 4.0
I would suggest using sockets. RPCs have slight overhead over sockets and not worth the effort unless sending structured data.
If performance is key then use a shared memory segment. Look up CreateFileMapping and MapViewOfFile on MSDN. You can start from the aptly named "Creating Named Shared Memory" available at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
Related
I have multiple processes that need to run simultaneously: reading and reporting data coming from serial device (plugged into OSDK device), transmitting telemetry data to MSDK device, and receiving and parsing incoming data from MSDK device. I believe that data transmission is supposed to be in the main thread, so would it be proper to separate the serial read into another thread?
This is my first time working with threading.
Thank you.
You don't have to use a separate thread, you can also use non blocking functions to try to read from the serial port. However a separate thread makes some things simpler, but the needed locking again makes it more complicated. What is easier depends on the details of your task.
I am building an music player using Background audio player agent on WP7. I want to enable communication between the UI part and the agent part. Many guides suggest using isolate storage, but I think that is not a good way
Is there any way to enable inter-process communication in Windows Phone 7
In Windows Phone 8 SDK, we can now use system-wide Mutex object.
It seems the foreground App and Background Agent run as separate processes on the phone. So even when you instantiate the same class, each process has a different instance.
The best solution I know about so far is to have each process map the "shared" data structure to an Isolated Storage file, then use a system wide Mutex (named Mutex) to prevent one process from reading the file when the other is writing it. It'll be simpler if one process is always the writer of the data structure, so it never has to worry about merging in changes made by the other process asynchronously. If each process must be the writer of some portion of the data structure, the usual case, consider separating those portions into separate data structures and separate Isolated Storage files, with one process reading one file and writing the other and the other process writing the first and reading the second. (all reads and writes within mutex. Use same mutex for both files and both processes to avoid deadlocks.)
try this:
phoneApplicationPage.State
I am going to tell the problem that I have to solve and I need some suggestions if i am in the right path.
The problem is:
I need to create a Windows Service application that receive a request and do some action. (Socket communication) This action is to execute a script (maybe in lua or perl).This script models te bussiness rules of the client, querying in Databases, making request in websites and then send a response to the client.
There are 3 mandatory requirements:
The service will receive a lot of request at the same time. So I think to use the worker's thread model.
The service must have a high throughput. I will have many of requests at the same second.
Low Latency: I must response these requests very quickly.
Every request will generate a log entries. I cant write these log entries in the physical disk at same time the scripts execute because the big I/O time. Probably I will make a queue in memory and others threds will consume this queue and write on disk.
In the future, is possible that two woker's thread have to change messages.
I have to make a protocol to this service. I was thinking to use Thrift, but i don't know the overhead involved. Maybe i will make my own protocol.
To write the windows service, i was thinking in Erlang. Is it a good idea?
Does anyone have suggestions/hints to solve this problem? Which is the better language to write this service?
Yes, Erlang is a good choice if you're know it or ready to learn. With Erlang you don't need any worker thread, just implement your server in Erlang style and you'll receive multithreaded solution automatically.
Not sure how to convert Erlang program to Windows service, but probably it's doable.
Writing to the same log file from many threads are suboptimal because requires locking. It's better to have a log-entries queue (lock-free?) and a separate thread (Erlang process?) that writes them to the file. BTW, are you sure that executing external script in another language is much faster than writing a log-record to the file?
It's doubtfully you'll receive much better performance with your own serialization library than Thrift provides for free. Another option is Google Protocol Buffers, somebody claimed that it's faster.
Theoretically (!) it's possible that Erlang solution won't provide you required performance. In this case consider a compilable language, e.g. C++ and asynchronous networking, e.g. Boost.Asio. But be ready that it's much more complicated than Erlang way.
Usually, when an application writes to one of it's files on disk, the file modified timestamp changes.
Sometimes, and in my case it is an application written in ProvideX (a Business Basic derivative i believe) doing the writing, the modified timestamp does not change after a write. A program like MyTrigger will not pick up on the write operation either, but Sysinternals ProcessMonitor does log the disk activity.
It seems obvious that there are different ways to ask windows to perform write operations, and the request could then be hooked or logged in various different ways as well.
I need to be able to hook the write operations coming from the ProvideX application. Any pointers on the different ways windows writes to disk, and the type of hooks available for them would be greatly appreciated.
Thanks
User-mode process can write to the file either using WriteFile API function or using MMF, memory-mapped file API (CreateFileMapping/MapViewOfFile/Write to memory block). Maybe your application goes MMF way. MMF writes to files very differently from WriteFile API, but they both lead to the same end point - IRP sent to file system driver. File system filter driver (such as the one used by Sysinternals stuff) can track write requests on that IRP level. It is technically possible to distinguish between write operations initiated by MMF and WriteFile as different IRPs are sent (cached and non-cached writing is involved). It seems that directory change monitoring function in windows tracks only one IRP type, and this causes MyTrigger to miss the change.
we have a windows service running and we also have a console application that we use to configure this service, we also have an option to see some log being recorded.
The very ugly thing with this is that this communication is made by a text file, the console app writes to a text file and the service reads it and vice versa.
What would you use for this communication? TCP/IP is not an option because the console app will be used for the local running service only.
Windows API SendMessage should be the way to go?
thanks!
I would recommend WCF as the first thing to consider for all comms on windows if using .net as its built for this kind of thing and its relatively easy to use. Since you're excluding TCP, I'd suggest using the Named Pipes Binding.
There are also an number of windows comms apis available for intra-machine comms. Named Pipes (as mentioned), MailSlots, Shared Memory (Memory Mapped files) etc.
My suggestion would be be use Named Pipes either with WCF or natively.
You run less risk of deadlocks if you use non-blocking methods of message passing. PostMessage, or SendNotifyMessage are better than SendMessage because they don't block the caller.
But they depend on the service having a window handle. Does it?
You can also use the WM_COPYDATA message, to pass more than just a wParam a lParam. If you use this message with PostMessage, you need to be careful not to free the memory until the receiver is done with it. It's safest to use SendMessage for WM_COPYDATA.
Shared Memory? See here for an article on Codeproject, here's another fastipc article on the same site. There's a blog entry detailing on how to use a memory mapped file for sharing via a wrapper.
Hope this helps,
Best regards,
Tom.