I am writing an application using SignalR which acts as a push service of resources for clients. The service sends notifications to its clients regarding state change of resources at regular intervals. Sometimes, the resource state remains the same. In such cases I need a way to convey the same to clients without sending the same resource again. In a way, I want to implement something like ETags with SignalR. To do that I need to modify SignalR response headers (or I could use query string).
Is there a way to do this?
you are saying to pass the same state to clients (But with NOT MODIFIED kind of header) as well not to pass if it is same.
In such case you should actually not pass any message to the clients if the server hasn't anything new to give to the clients. This is how realtime applications are supposed to work.
Also instead of adding an overhead of extra HEADERS why don't you just send a simple actual signalR ping to the clients saying "Hey, nothing modified. Just chill!"
Related
In database some entity is getting updated by some backend process. We want to show this updated value to the user not real-time but as fast as possible on website.
Problems we are facing with these approaches.
Polling :- As we know that there are better techniques then polling like SSE, WebSockets.
SSE :- In SSE the connection open for long time(I search on internet and found that it uses long polling). Which might cause problem when user increases.
WebSockets :- As we need only one way communication(from server to client), SSE is better then this.
Our Solution
We check database on every request of user and update the value.(It is not very good as it will depend upon user next request)
Is it good approach or is there any better way to do this or Am I missing something about SSE(misunderstood something).
Is it fine to use SignalR instead of this all?(is there any long connection issue in it or not?)
Thanks.
It's just up to your requirements what you should use.
Options:
You clients need only the update information, in the case they make a request -> Go your way
If you need a solution with different client types like (Webclient, Winformclient, Androidclient,....) and you have for example different browser types which you should support. Not all browsers support all mechanisme... SignalR was designed to choose automatically the right transport mechanisme according to the mechanisme which a clients supports --> SignalR is an option. (Read more details here: https://www.asp.net/signalr) Has also options that your connection keeps alive.
There are also alternatives like https://pusher.com/ (For short this is only a queue where you can send messages, and also subscribe for messages) But these services are only free until for example some data volume.
You can use event based communication. When ever there is a change(event) in the backend/database, server should send a message to clients.
Your app should register to respective events and refresh the UI when ever there is an update.
We used Socket IO for this usecase, in our apps and it worked well.
Here is the website https://socket.io/
Using Rebus, is it possible to have more than one transport configured within an application?
Our business domain is image processing, due to the potentially large size of the images being processed, I would like to use an InMemory transport for communication within one service (WebApi 2) to tokenize (Guid) and persist the images to be processed into a database.
In addition, after the images are tokenized we would like to used the RabbitMQ transport to send the images for processing to the ImageProcessingService (Console App - using TopShelf), and reply back to the calling application (WebApi) once processing is complete.
I cant seem to figure out the correct way to handle the scenario where I would like to use messaging within an application (WebApi) using an InMemory transport, and also have the WebApi able to send to the ImageProcessingService via the RabbitMQ Transport.
Obviously I don't know the details of your problem, but did you consider saving the image data somewhere else (a network share, MongoDB GridFS, a SQL Server LOB, etc)?
In my experience everything turns out to be easier to handle if you use messages for coordination only, and not so much for transporting the actual bulk of the data.
PS: I did experiment with a multi-modal transport at some point, which would allow you to do something like this:
Configure.With(...)
.Transport(c => c.Multi()
.Add("amqp", t => t.UseRabbitMq(connStr, "rabbitqueue")
.Add("inmem", t => t.UseInMemoryTransport(network, "inmemqueue"))
.Start();
and then specify addresses on the form amqp://rabbitqueue and inmem://inmemqueue to address the configured endpoint via RabbitMQ and in-mem transports respectively.
It would simple wrap any number of transports which you would then need to qualify with a protocol, which could be anything you would feel would be appropriate.
This way of addressing turned out to raise a bunch of questions though, so it wasn't that simple to introduce.
It is quite easy to update the interface by sending jQuery ajax request and updating with new content. But I need something more specific.
I want to send the response to client without their having requested it and update the content when they have found something new on the server. No need to send an ajax request every time. When the server has new data it sends a response to every client.
Is there any way to do this using HTTP or some specific functionality inside the browser?
Websockets, Comet, HTTP long polling.
It has name server push (you can also find it under name Comet technology). Do search using these keywords and you will find bunch examples, tools and so on. No special protocol is required for that.
Aaah! You are trying to break the principles of the web :) You see if the web was pure MVC (model-view-controller) the 'server' could actually send messages to the client(s) and ask them to update. The issue is that the server could be load balanced and the same request could be sent to different servers. Now if you were to send a message back to the client you'll have to know who all are connected to the server. Let's say the site is quite popular and you have about 100,000 people connecting to it every day. You'll actually have to store the IPs of each of them to know where on the internet they are located and to be able to "push" them a message.
Caveats:
What if they are no longer browsing your website? You see currently there is no way to log out automatically if you close your browser. The server needs to check after a fixed timeout if you have logged out (or you send a new nonce with every response to prevent the server from doing that check)
What about a system restart/crash etc? You'd lose all the IPs that you were keeping track of and you are back to square one - you have people connected to you but until you receive new requests you can't really "send" them data when they may be expecting it as per your model.
Let's take an example of facebook's news feeds or "Most recent" link close to the top right - sometimes while you are browsing your wall you see the number next to most recent has gone up or a new 'feed' has come to the top of your wall post! It's the client sending periodic requests to the server to find out what was updated rather than the other way round
You see, it keeps it simple and restful. You may feel it's inefficient for the client to "poll" the server to pull the data and you'd prefer push, but the design of the server gets simplified :)
I suggest ajax-pulling is the best way to go - you are distributing computation to the client and keeping it simple (KIS principle :)
Of course you can get around it, the question is, is it worth it?
Hope this helps :)
RFC 6202 might be a good read.
Since the Flash Player (or, more exactly, the URLLoader class) will not let you read HTTP response headers or cookies set by the server, and if you get hold of a session cookie through some workaround like reaching out to the browser and run JS, you can't send it to the server, because, among others, the Cookie header will be blocked.
Now I'm building a Flex client against an HTTP API for my server product. I control both sides, so I can get get around the above limitations, now I'm wondering how. I see the following options:
include the session token in the HTTP payload
include the token in the URL
build my own HTTP client (... with blackjack, and hookers ...) in AS, using the Socket class
I don't like (1), because I'm reimplementing functionality in my protocol that is already built into Struts, which I'm using to implement the server side. I then have to ensure that either both behave the same way, or turn off the usual way of session management and force other clients to use my protocol where they could just have the browser deal with it.
I don't like (2), because I understand that there are security concerns with this, although I'm not too sure which
I don't like (3), because it's 2010 and tons of HTTP clients have been written by smarter people than me.
So, are there other opportunities? Which of my "don't like"s do you reckon least severe? Are there ways to mitigate the problems I listed? For example, how insecure are session tokens in URLs really?
How about using the FlashVars parameter? It's designed explicitly to pass simple data into a Flash app, and it's trivial to embed the session token into the tag when the page is generated server-side. PHP-wise, it'd be something like
<embed href="movie.swf" flashvars="sessionID=<?= session_id(); ?>">blah blah blah</embed>
This way there's no session data in the movie's url that could leak via referers, and the data's already "there" so the app doesn't have to reach out and talk to the browser. And if someone's sniffing the source HTML page to get the data, they could have gotten the same information from the HTTP headers anyways.
There's more details here in the Adobe docs.
Some of your post may have eluded me, but do you know about Shared Objects:
"The SharedObject class is used to read and store limited amounts of data on a user's computer or on a server. Shared objects offer real-time data sharing between multiple client SWF files and objects that are persistent on the local computer or remote server. Local shared objects are similar to browser cookies and remote shared objects are similar to real-time data transfer devices.
Scenario:
localhost receives the current HttpRequest with 3 hidden inputs and a posted file. I must then forward this form data to an external image host and get the response.
See the System.Net.WebClient and related classes. You can use them to create a request to the remote server and handle the response. Also get Fiddler to help you replicate what the browser sends.
I hate doing this. It wastes my server's bandwidth and ties up IIS threads as well as using my server's CPU. It sucks and it's worth avoiding at all cost. Many services like, one that comes to mind is fliqz, provide a mechanism such that the files are uploaded directly from the client to their server (bypassing yours) and then they make a request to your server passing it various info on the query string.