I would like to create a web project using ASP.NET MVC 4 which aims to make use of XMPP for some of its messaging, I have good knowledge of Jabber.net however, what I am a little confused about is the threading model I need to implement to use this type of library with an MVC application.
For example, when a user clicks a button on my page, on the server side, I want to:
connect to the XMPP server
then authenticate
then send an IQ message
then receive a response back
After all this is done, I then want to send the HTTP response message back to the client.
All of this is done using standard event handlers within Jabber.net but this model doesn't traditionally fit with web based threading, unless I am just tired and missing something...
Should I use a WaitHandle to stop the controller thread until the other threads are done with the Jabber.net code, then respond?
Do the async controllers fit here?
Related
I have two Projects, an Asp.net WebAPI & a separate Single Page Web Application. My requirement is that when a form is submitted via the web application it is processed at the Web API. Once the Request has been handled successfully i want to broadcast a message to all the clients notifying them that a new request had been submitted.
How can I do it? Any help would be appreciated.
I looked into SignalR, but couldn't find an implementation for this requirement.
Pusher's got libraries you can use to handle anything notifications https://pusher.com/docs/libraries
I suggest you use signalR to cater your requirement. You can go thru this link https://learn.microsoft.com/en-us/aspnet/signalr/overview/getting-started/ for more details.
If your project is small use pusher "https://pusher.com/"
when you use that well It may be cheaper than you make And less resources.
Let's say I have a web application that is an auction site. It employs ASP.NET Web API to query the server for business data but SignalR is also used for certain real-time aspects of the site. For example, if User A makes an auction and User B puts a bid on it, User A gets notified in real time that someone has put a bid on his auction. If User C also puts a bid on the same item, User B also gets notified that he has been outbid.
Given this scenario, I'm wondering whether it'd be "correct use of the toolset" to simply use a SignalR hub to call into the service layer to update the appropriate objects in the database as well as pushing the notifications to the appropriate clients. Or, should I use a Web API controller to do the service layer call which performs any db manipulation and get a hub instance through OWIN Context and only use SignalR for broadcasting?
What are the advantages/disadvantages of each approach? I guess the second option is the correct way, but I don't have anything in my mind to support it... it just feels more correct.
I'd also point out that Web API isn't used for no reason - I think that an auction application is such a thing for which dedicated mobile/tablet applications would perfectly make sense to be made and having a way to get data independently from view markup is pretty much what Web API is made for. The same applies to sending data to the server - representing actions as HTTP verbs and urls is something that I like to think of as a sort of a convention, so I guess using SignalR for such actions would kind of break the whole point of using Web API.
I am creating an ASP.NET MVC website that uses a 3rd party API (web service) as a data source. It is read-only, and to date has been accessed by individuals using desktop applications (most in C#). I would like to consume this API using a web site in order to centralize information and give users historical information, automate certain repetitive tasks, and more easily allow sharing of information among users.
The desktop clients today experience throttling, and if you make repeated requests to the API using a client your IP will be throttled and/or banned. I think that if I made the requests to the API from my website, its IP would be banned the moment it saw any significant use.
Let's assume that I cannot work something out with the API owners. Probably the easiest way to work-around this problem is to do all of the API access using AJAX. When the user visits the website, he makes the requests to the API using AJAX then turns around and posts them to my website. I don't like this idea for multiple reasons-- first, it'll be slow, and second, I could not guarantee that the data sent to my website was genuine. A malicious user could, for whatever reason, send me bad information.
So I thought a better idea would be to establish a man-in-the-middle. The user would still be forced to make the AJAX request, but they would make it to a proxy or something else that I control, which would then forward it on to the real API and intercept the response so I could be a little more certain that the data I retrieved was genuine.
Is it possible to create such a "proxy"? What would it entail? I would like to do it using a .NET technology but I'm open to any and all ideas.
EDIT: It seems I caused confusion by using the word "proxy." I don't want a proxy, what I want is a pass-through that allows me to intercept the response from the API. I could have the client make the request and then subsequently upload it, but I don't want to trust client, I want to trust the API.
Let me explain this in shorter form. There is a client on a user's machine which can make a request to an API to get current information. I would like to create a website that does the same thing, but I am considering the possibility that the API web service may notice that while previously it was receiving ten requests for ten users from ten different IPs, it is now receiving ten requests for ten users from one IP and block that IP seeing it as a bot even though every request was kicked off by a user request just as it had previously. The easiest way to workaround this is to have the user make the request and then upload the response to me, but if I do that I am forced to blindly accept data from a client which is a huge no-no for any website in any situation. If instead I can place something that forwards the request along to the API preserving the IP of the user but is also capable of intercepting the response thereby proving that the data is authoritative, that would be preferred. However, I can't think of a software mechanism to do this-- it seems like it would need to be done at a different layer.
As for legal concerns, this is a widely used API with many applications and users (and there are other websites I have found using the API), but I was unable to find any legal information like terms of service beyond forum postings in the API's tech support section amounting to "don't make repeated requests, obey our caching instructions" etc. I can't find anything that would indicate this is an illegal or incorrect use of the web service.
You could implement your proxy. It wouldn't need to be AJAX though, it could just be a normal web page request that displayed the API results if you wanted.
Either way, in .Net you could do it using ASP.Net MVC. If you wanted AJAX, use a Web API controller action that implements the source API, if you want a web page, just use a regular MVC controller/action.
Inside your controller, you would just make a web request to the source, passing through the parameters.
In order to avoid throttling, you could cache the results of each request you make from your server (using the normal ASP.Net cache), so that if another client attempted to make the same request, or a similar one maybe, you could return the cached results instead of making another request to the API.
You would have to determine how long the results should be cached for, depending on how up to date the data needs to be in your client. E.g. For weather data, caching for an hour would seem OK. For more fast moving data it would have to be less. You have to strike a balance between avoiding throttling and keeping data fresh.
You could also intelligently fetch more data than you need at each request and then filter the result set that you return to your client. This could give you a better cache hit rate.
I have 2 web forms applications written in c# asp.net. This is the kind of thing I need:
A user clicks a button in web app 1
Web app 1 needs to send some parameters to web app 2 and get a response
Web app 1 uses the response from web app 2 to finish processing the post-back
User is happy
So I guess I need to incorporate some kind of web service thing into my web applications? Please point me in the right direction.
Update:
I've done some more research and found that WCF seems to be a goer. I have used WCF once before (stumbled through it) but how do I use WCF inside a web application - or do I need to create another application just for WCF?
Inter-process communication is a pretty large topic and there are many ways to do it.
Some tings to consider are
Synchronous vs Asynchronous - What should be the behavior if the user clicks the button twice in quick succession?
What should happen if user clicks the button but the web app2 is down for a few minutes?
Authorization and security
Denial Of Service style attacks
For something of this nature I would be inclined to use something like a message-queue maybe managed by something like nservicebus it would be a very simple, yet robust solution. WCF is another option and so is MVC 4.0 web services.
I want to use MvcMailer in a class library, which would essentially be my one-stop-shop for composing and sending emails for my solution. I thought that that is what MvcMailer was designed for, but it appears it cannot find any of my .cshtml files--I guess it expects them to in my startup project.
Is there any way for MvcMailer to be 100% separate from my other projects?
Thanks.
This is not possible according to MvcMailer documentation https://github.com/smsohan/MvcMailer/wiki/MvcMailer-Step-by-Step-Guide (extract below), maybe you can have a separate web project that its only purpose is to send emails and only accept requests from your application
Email Sending from a Background Process
Do you need to send emails from a background process? Yes, you're right. You don't want to block your request/response cycle for that notification email to be sent. Instead, what you want is a background process that does it for you, even if it's sent after a short delay. Here's what you can do:
Save your email related data into a database.
Create a REST/SOAP web service that sends out the emails. This will ensure your Mailer has access to the HttpContext, which is essential for the core ASP.NET MVC framework to work properly. For example, to find your views, produce URLs, and perform authentication/authorization.
Create a simple App that calls the web service. This could be a windows service app or an executable app running under Windows Scheduled task.
A future version of MvcMailer is likely to have support for this. But it is hard because of two reasons:
MailMessage is not Serializable out of the box and has a lot of complex fields and associations.
The core ASP.NET framework still needs HttpContext :(