How can I send and retrieve messages in Windows without the MSMQ feature?
MSMQ is a network protocol so as long as you can write the data onto the wire in the right format, you'd be able to avoid installing MSMQ but normally you would make use of the installed MSMQ feature to handle all the messaging, handshaking, storage, etc.
In theory you could write your own queue manager application to replace what Windows installs for the MSMQ feature. For example, you may want to do that on a non-Windows platform.
As writing your own queue manager is a significant development project, most people don't bother and instead use what's there already.
Related
I am trying to figure out what the best way to communicate between a GUI and a Windows system service is. Named pipe seems to be a good option because it has built-in access control mechanism to protect the channel. I found that VPN apps actually use named pipe for communicating between their GUI with system services, such as ExpressVPN and NordVPN.
It seems that these VPN apps don't use basic Windows APIs for creating named pipes (i.e. CreateNamedPipe) but some other libraries or APIs because the behavior of these apps is almost the same: The system service, which is installed by the app, creates a named pipe with a name in this format: (app_id)(username):SingleInstanceIPCChannel or a random GUID string (e.g. 64de4b4e-96e2-4444-8946-f96888f5f3bd)
Anyone knows which library or APIs have this behavior?
I have successfully updated a MassTransit app from 2.x to 3.x and switched to RabbitMQ for my transport. I did this to get one-to-many messaging to function properly, which the previous developer thought would work with MSMQ but I found it was not working and it became clear by reading the documentation that I would need to use 3.x and RabbitMQ.
My application has multiple instances of a website running on the server, with each instance for a specific customer base. I want each instance to publish to specific queues so that the data is only available to the back-end processes for the particular instance. I can easily configure each of these processes to only read from specific queues, but how do I get MassTransit to publish only to specific queues.
You should probably configure a separate RabbitMQ virtual host for each customer, and point that customer's web site instance to that specific virtual host. That way, each way site has its own virtual service for message traffic, keeping it isolated from the other.
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.
(Also asked over on ServerFault, where I was advised to post it here too)
We have a requirement to send desktop alerts to various users (compliance, production) across a network when other users have submitted content online for a report.
At present we are using NET SEND but this has no guarantee of delivery and has proved unreliable from both client and server perspective (and I gather will be unsupported in later versions of Windows; we are currently running XP).
We are considering a Jabber-based solution but has anyone used a Jabber client to pop up alert messages on the screen like NET SEND does, as opposed to just bringing a chat window to the front or displaying a temporary 'toast' message near the system tray.
We need the alert message to be persistent and only dismissed by the user, indicating they have seen it. Toast-style pop-ups would be fine as long as it was not only for a limited time and again had to be dismissed by the user.
Any solutions?
Openfire is a java based Jabber server that seems to be targeted to a corporate/business environment and provides the "toast" message feature with their Spark client. They also offer several other useful business-focused features.
Offline message delivery is not guaranteed by XMPP specification. It depends on concrete server implementation. Moreover, it has cost in supporting user accounts.
As an out-of-box solution it is fine, but since we are in development community, I would
consider building alert system using MessageQueue for guaranteed delivery.
The message-delivery semantics of XMPP are liable to be a good fit for your application, since you're not talking about financial transactions that require fiduciary-level delivery guarantees. It will certainly be better than NET SEND by a lot.
Write a simple client that listens for messages and does the pop-ups in whatever format you want, and have the program run in the background, perhaps with a tray icon. Writing something like that with Jabber-Net would be the work of a few hours, for example.