I'm using EF (6) with ASP.net MVC (c#). My hardware architecture:
main server - include windows service.
web-server - running my web-application UI.
The users request for some answer. My web-site adds the question to the Data-Base (SQL - server) with EF.
In my main server, the service detects the changes (new task arrived) and solve it.
The detection of new task made by busy waiting, which I do not like.
How it's being done:
My EF layer includes custom function, which fire every N minutes SQL stored procedure.
If the SP retrieve information, the service solve it.
What I want:
when new task added from the web-site, the web-site will send signal to the main server. When the signal arrives to the main server, it will immediately start to solve it.
How this can be done?
Thank you!
seems like a perfect use case for singalR....
please take a look at http://www.asp.net/signalr
signalR will choose the best suited communication method. it also uses sockets if available otherwise fallback to other means of transport.
You can create one more service for Comm. between two servers .
Solution implemented with WCF is very trivial to Develop ..
Whenever new Question is posted .. your webserver can invoke this webservice ..
bottom - line : Look into WCF
We do this a lot, I think you have a few options:
A shared storage mechanism which is polled from the receiver (what you are currently doing)
Using something like a webservice call to send a command to the receiver (Normally a synchronous processing technique)
Using a messaging framework such as NServicebus to send the command to the receiver (an asynchronous fault tolerant technique)
We use all of these techniques, but the one I normally find best is the last one.
Messaging introduces fault tolerance and asynchronous processing which are both very useful when building systems spanning multiple machines.
If this sounds like something that might help check out the pubsub example for NServiceBus here: http://support.nservicebus.com/customer/portal/articles/860297-how-pub-sub-works
Or if fault tolerance doesn't really matter to you I would recommend a selfhosted webapi running inside your windows service.
Related
I have a Windows service written in C# that handles processing of digital documents, and a web application written in PHP. I need to be able to notify the C# service that new documents are ready for processing.
Currently, the C# service is reading the MySQL database every 10 seconds to see if there are new tasks to be performed. This creates a 10 second lag in the responsiveness of the web application. I'd like to be able to trigger the C# service immediately when the document is ready.
I'm looking for an answer that will allow PHP to notify the C# service without any delay.
Here are some possible ideas that I've had;
Use a shared memory object between PHP and C#, and have a thread in C# wait for that object to be signaled. Is this possible with PHP?
PHP connects to C# using a socket on localhost, sends a nak and disconnects. This seems inefficient to me.
Configure MySQL to use an in-memory table, and have the C# service query the table every second.
Is it difficult to create some kind of web service in C# that uses XML or SOAP, and would there be any lag (+1 second) in calling that service via PHP?
That's all I can think of. Maybe there is some kind of standard way this should be done, and I'm just not aware of it.
It'd be pretty trivial to make a REST facade in WCF that triggers your c# service on a POST against /. Security can be layered on depending on the nature of your deployment.
http://msdn.microsoft.com/en-us/library/bb412178.aspx
I'm going to go ahead and try to answer this.
In your service, add an OnCustomCommand handler as described in this question to trigger the service work: How to send a custom command to a .NET windows Service from .NET code?
Create a separate C# application that simply sends the command to your service and call that from PHP via the exec() function.
You could self-host an ASP.NET WebAPI in your service
Scenario
I have a Windows service that is in charge of listening for various things and act accordingly. Most of the time this service modifies the database in some fashion (adding, removing and cancelling items). This is on the servers side and requires no user involvement. The client side is quite simple. Each user (5-10) each use an application to work on the items inserted by the Windows service.
Problem
The issue is that the clients are working in a disconnected state. What I mean by that a client could reload their list of items needing to be worked on and 5 minutes later actually begin their work.
Also, due to various issues no administrative assistance must be required in order to install the client application. This rules out libraries such NServiceBus (or any library requiring the use of MSMQ) and WCF (seems like so because it requires the use of opening up URLs using netsh http add urcl.
I'm not looking to send messages to clients. All I'm looking for is an easy way to have the Windows service poke each subscribed client instructing them to reload their list. I do realize that I could simply create a background thread (or the like) and refresh every n minutes but there's really no sense in doing that (IMO) if nothing has happened in the last few hours.
Edit
Researching some more it appears I can use raw sockets for this. Will update once I get something working.
Take a look at 0MQ, it might meet your requirements.
I want to design a new distributed application, but I have a few queries that I need some genius advice on, hopefully from you people:
Scenario
I currently support a legacy application that is starting to fall between the cracks.
It is a distributed Client-Server app implemented using .Net Remoting. I can't explain exactly what it does, because I'm not allowed to.......But let's just say that it does LOTS of MATHS. I want to re-design and re-write the application using WCF.
Pre-requisites
The server side of the implementation will be hosted in a Windows Service.
The client side will be a windows forms application.
The server side will perform lots of memory-intensive processing.
The server will spit this data out to multiple thin clients (20-ish).
The majority of the time the server will be passing data to the clients, but occasionally the clients will be persisting data back to the server.
The speed at which the data is transmitted is highly-important, however I'm well aware that WCF can handle fast distribution of data.
Encryption/Security is not that important as the app will run on a highly protected local network.
Queries
Given the information above:
1)What sort of design pattern am I best going with? - Baring in mind I want the server to continually PUSH the newly calculated information immediately to the clients, as opposed to the current implementation that involves the client pulling from the server continuously.
2)What type of WCF binding should I use to ensure maximum speed of data transfer? (as close to real-time as possible is what I'm after)
3)Should I use a class library to share the common objects between the client and the server applications?
4)What is the best way in which to databind my objects on the client side in order to see live updates continually as data changes?
If I've forgotten anything then feel free to point this out
Help greatly appreciated.
1) What sort of design pattern am I best going with?
Based on your comments, you're wanting to transform the current polling mechanism to an event-based mechanism. That is, instead of the client constantly checking the server for results, have the server notify the client when a new calculation result is available.
I would recommend using Juval Lowy's Publish-Subscribe Framework for this.
(source: microsoft.com)
.
This framework is described in detail in this MSDN article. And you can download the framework's source code for free at Lowy's website, IDesign.net.
Basically, the server logic that performs the calculations inside the Windows service is the Publishing Client in the graphic, and the various WinForm applications are the Subscribing Clients. The Pub/Sub Service lives in your Windows service. It manages the list of subscribing clients and provides a single endpoint for your server to publish calculation results to. In this way, your server performs a calculation and publishes the result once to the Pub/Sub Service endpoint. The Pub/Sub Service is then responsible for publishing the result to the subscribed clients.
2) What type of WCF binding should I use to ensure maximum speed of data transfer?
If all of your WCF communication were on a single machine, you'd want to use the NetNamedPipeBinding. However, since you will be distributed, you want to use the NetTcpBinding.
For WCF binding decisions, I have found this chart useful.
3) Should I use a class library to share the common objects between the client and the server applications?
Since you are in control of both the client and server side, I would highly recommend sharing a class library instead of using Visual Studio's "Add Service Reference" feature. For a detailed discussion of this, refer to this SO question-and-answer.
4) What is the best way in which to databind my objects on the client side in order to see live updates continually as data changes?
I suspect this will depend on what controls you use to display the data. One way that immediately comes to mind would be to have your client fill an in-memory data table as each calculation result is received. This data table could then be bound to a ListBox control, for example, that shows the results in calculation order.
This to me looks like you need to implement the Observer pattern, but distributed. Whereby new calculations are made to the service, and WCF just happens to be the mechanism by which you push your notification back to the client.
Generally speaking, you have your business logic housed in a windows service, whereby a type is a Subject (Observable). You could publish an endpoint for clients to register for notifications. This would be a WCF service, with potentially two operations:
RegisterClient(...)
UnregisterClient(...)
When a client is registered with service, it can receive updates, broadly speaking, the when the service has finished calculating a result, it could iterate through all registered clients and initiate a push. The push being a communication through an endpoint on the client.
A client endpoint might typically by
Notify(Result...);
And your server simply calls that when it has new data...
Typically you'd use TCP to maximise throughput.
This is by no means exactly what you should do, but perhaps its a direction to start in?
I'm trying to use WCF to implement a comet style server push to an ajax web application.
In my WCF service, I've implemented a WaitForEvents method that calls Monitor.Wait to suspend the thread until new data arrives. At that point, the Monitor is pulsed, and the method returns the new data which closes the comet style request.
The request is made again when this happens.
Currently, this works fine but I noticed that WCF needs to create a new thread for each connected user. This is probably because the thread cannot be returned to the threadpool until data comes in, and so each connected user requires a new thread.
I want to make this implementation more efficient by having one thread service multiple connections. If I were to use a socket, this could be done by leaving the socket open and returning the thread to the thread pool first. When new data arrives, it will be delivered by another thread and we can write the new data directly to the socket and close it.
Does anybody know how this can be done via WCF?
I have been looking at "Push-Style Streaming" http://msdn.microsoft.com/en-us/library/bb472551.aspx and they mention that "WCF implements a "pull" model in which the application code (the service) returns an instance of Stream and relies on the lower-level infrastructure to pull data from this stream and write it out to the network." but I cant find any examples of this one the website.
Many thanks in advance!
Check out nComet
It's not using WCF, but I believe the author is working on a version that uses WCF. Contact him via codeplex and ask him :-)
"nComet is a .NET implementation of
the Comet (reverse-AJAX push)
architecture. This server-side
pipeline uses long-lived
client-initiated HTTP connections to
push messages to the client. Once the
client receives a response, it
immediately opens another HTTP
request, which the server holds until
a message is ready. This architecture
allows the server to push dynamic
html/xml/json/etc to the browser,
rather than the browser polling the
server.
This project is scoped to the .NET
server-side architecture, initially
providing a HttpListener (for a custom
host communicating with HTTP.SYS
directly) as well as a ASP.NET
implementation, where the ASP.NET
implementation can be hosted inside
IIS as well as an external process.
The library will simplify the
implementation of common message
patterns such as pushing the latest
data, as well as sync. Example code
and links to multiple client-side
javascript implementations will also
be provided."
You may also want to check out WebSync, a .NET comet implementation. Works just dandy with WCF.
(Disclaimer: I work for the company).
I'm developing some kind of server service who gets in action and stop on an specific range of time, I need to write a monitoring app to receive some status text sent from the service in the same local host.
It's the first time I need to comm between processes, I've been looking for some methods, wich do you believe is the best for this case? why? pros and cons for each one?
Remoting
Named pipes
Windows messages
local tcp connection
Database table log (I'm using a database so it's another option)
Datafile on disk
Edit:
I'm using .net 2 so the great wcf solution doesn't work for me :(
See this SO question:
C# IPC Best Practises
You almost certainly want to use WCF. This replaces other .Net technologies such as remoting. Also, if you use WCF:
Other clients could also subscribe to that status information in the future.
The service listening to status updates could be run on another physical box if you needed to scale out.
If you're really just looking for "status messages" - as opposed to an actual client app - then you can use Trace/Debug.Write* statements. DebugView will pick them up if it's running, and can also be used across hosts. And, of course, you can add other listeners via config file if you later wanted to save the messages.