I have a web page where I redirect the user to if I see that IP is not valid. I want that user's browser will get no response but kept into waiting state, but I also want that my server thread is not blocked for that request. So the idea was that server will response quickly but the user' browser will put into waiting loop to discourage the user. How can I achieve this easily? Is it possible without JavaScript? If JavaScript is the only way then suggest that solution.
Thanks
The problem here is that HTTP is a request/response protocol. If you are redirecting the user, you're responding to that original request. Unless the user generates another request (via javascript or whatever) then the server can't respond again.
You don't need to put the browser into a 'waiting state', if the server simply doesn't reply to the request the browser will just keep on waiting.
I think you're trying to say that your IP task takes a long time, and how to deal with that effectively?
Perhaps if you clear up your question I can answer more fully.
No this is not possible. The problem is to keep the browser waiting with no response you need to keep the connection open and not write to it. The result of this will be:
It will cause your server to run out of connections and use memory to maintain connections
The client will timeout, even if you do not reply
You could purhaps reply with a page that contained a java script with an infinate loop.
Related
The logic of my code is basic.
The user sends a request to the server side, where it is processed and shown in an admin panel. Afterwards a person with access to the admin panel analyses the data and sends a response with some delay.
How can I create a response listener on the client side, so that I can catch the message I get from back-end, no matter the delay?
I tried doing it with fetch, but no wonder it didn't work, because once it is compiled, it makes the action immediately. Is AJAX an option in my case?
You'll need to have some sort of bidirectional communication layer here. The most common approaches are polling, web hooks, or sockets. Polling will probably be the easiest to set up in a beginner use-case.
If you're referring to jQuery's $.ajax, which uses XMLHttpRequest, it's not likely to be a good idea unless the server can respond very quickly every time. From what I understand, if the request isn't fulfilled within a reasonably short period of time, the browser or OS will terminate it. Fetch might have different limitations, but I still wouldn't trust it for something like this.
There are better approaches. Either create a websocket, so that the server can push information to the client on demand, or (less elegant) have the client repeatedly make requests to the server (say, every minute) and have the server respond positively if/when the admin panel has been dealt with.
I'm building a webpage with some interactions between users and I'm a bit lost.
Any guidance is welcome.
Imagine the following scenario:
Client A opens a 'public' webpage and pressess a button.
Client A starts waiting for the response of client B
Client B goes to an 'admin' webpage and presses a button.
Client A receives the information that client B had pressed a button.
The overall idea to have a page were client A can click a button "I'm ready to play" and starts waiting for client B's response. Client B receives a notification and presses a button "I'm ready too". Client A receives a notification telling Client B is ready too.
I know this could be done with AJAX. But I'm not really sure how to 'wait' for the client B response and update the webpage when the response arrive.
Any help / tip is welcome.
Thanks for your support.
Asynchronous
You seem to think in synchronous way, but that's not how you should think about this. You are issuing a command to the server, but you should not wait for the response, because:
the command might never arrive, for ex. due to Internet connectivity issues
the server might be down
the server might error out your command and never respond
the other player might never receive the message
the other player might never answer the message
the server might never receive the other player's command
the server might error out the other player's command
the server might never send you the notification
you might never receive the notification
So many point of possible failure on the one hand. And... Javascript is single-threaded on the other hand. So, if you wait for the other player to respond, then your UI will froze in the meantime (with the exception of Web Workers, but that's a more advanced topic, for now, let's view Javascript as a single-threaded environment)
Instead you should think asynchronously. In fact, in the achronim of AJAX, the first "A" stands for "Asynchronous". This means that you issue a request and define what you will do when a response is received. This "what will you do" is called the callback. Your client-side will work and be responsive in the meantime and when a response arrives it will know what to do.
Not only your request, but the other's response
Okay, now that we think asynchronously, we need to consider our options to handle when the other player decides to join your game:
Polling
You may issue periodic requests to the server via setTimeout and AJAX requests and once the response notifies you about the game being accepted, handle it accordingly. See: https://davidwalsh.name/javascript-polling
Push notifications
The server may send notifications to the users once an event occurs. See: https://onesignal.com/lp-web-push?utm_source=google&utm_medium=cpc&utm_campaign=general&gclid=CjwKCAjw4_H6BRALEiwAvgfzq9s03BR1OhlvxwN6SCn6Q_bIKODk3bQK05gwdaHTpwvzV2d7mXQU9hoCSl4QAvD_BwE
But you may want to use something that's compatible with what you are using at the server.
WebSockets
WebSockets are duplex channels, which are kept open. If the framework is implemented and supported, then client A and client B would both be connected, client A would send a command via WebSocket, the server would receive that and notify client B via WebSocket. When client B decides to accept the challenge, he would click on the button, which would issue a command of his own to the server via WebSocket and the server would notify client A via WebSocket. See: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
Summary
It's better to view this as a series of events and event handlers, rather than waiting for a response.
I'm going to write an application, having some worker threads on the server, and some log and status elements on the html page. logs and status are expected to be updated whenever an update is ready from the server side.
well, one approach is to set up a polling mechanism, like the client sends a request on specified intervals and the server sends back the last update, (if any available).
however I wonder if there is any more efficient way like an interrupt-driven approach, on which whenever an update is ready on the server a message is sent to the client through an Ajax call. and as long as no update exists no message is transferred back and forth.
first of all, is this possible to initiate a call from the server side? I mean via Ajax.
or is there any library like JQuery that facilitates such a requirement?
Thanks
Consider using web sockets (Available in HTML5) - This will allow you to skip polling an update the data immediately as the server sends up his finish request.
Read more on:
http://www.html5rocks.com/en/tutorials/websockets/basics/
This is a followup question to the one here
Here's briefly what I am trying to do. The File server creates a text file to indicate an end of the process. On a webpage on the Web Server, I loop every x seconds and make an ajax request to find out if the test file exists (ajax request to http://fileserver/files/UserFile.txt)
I've tried the following approaches so far:
Trigger a web method from the client side that creates a HttpContext object to verify if the text file exists. But this is too strenous on the server and I started getting all kinds of exceptions in the Event Viewer.
YQL works great but unfortunately it's too slow. The user waits atleast twice the amount of time.
I am looking for a solution that doesn't involve the server side. Somehow, I'd like to use JQuery to verify the existence of a text file on the fileserver.
Any thoughts?
You should be able to use JSONP and JQuery.ajax() to do cross-domain request work. Play with the jsonp and jsonpCallback attributes. Alternatively, you can use JQuery.getJSON().
Serving a single file from the filesystem is the most simple operation a web server can do. If that is already too much, then all other solutions will be worse. Find out why the server takes so long to serve a simple file and fix that.
Note: I'm assuming that the file is small since you say "test file". If it's a big file, the server will actually send it to the client which will need a lot of resources.
What you can try is to add an ASP page to the web site which runs code on the server that checks whether the file is there and just returns a tiny piece of HTML which you can add to the page with jQuery.load().
I may be miles off base here but... could you not create ONE asynchronous (!) Ajax client request with a HUMONGOUS timeout. Fire it, and wait. You would be invoking some server script that checks every so often, in a loop on the server (using sleep in between), whether the file exists. And not replying to the Ajax request until the file finally shows. The server script then replies and exits.
EDIT: Depending on the server-side scripting framework used, you may even get some OS support. You may be able to sleep on a status change in the directory...
In my application, the client is a Javascript set of functions in the browser, and it does some work - for example, playing a clip.
It uses XmlHttpRequest to talk to the server.
However, the server is allowed to abruptly close the connection since there is no other way it seems, to interrupt the client.
Can the client detect, while it is playing the clip, that the connection was closed, and so print a message and erase the page?
Any help appreciated.
thanks,
Anil
If the clip is streamed to the client, you could just stop serving it.
However, it seems like the clip is being downloaded and then played through the browser. In this instance it's probably best to use a watchdog approach as described by CookieOfFortune: Poll the server regularly (once a second or so) and get it to respond with tiny message of confirmation. When the connection is closed, get the server to respond with a negative messgage.
Unfortunately, without using a comet-like system, it's very hard to get the server to 'send' a message indicating session closure.
Bear in mind though, that as soon as the client has downloaded a clip they will be able to play it in full if they want to. Unfortunately there's no way to stop this besides switching to a streaming approach. If securing your content is a priority, I'd suggest making this change.
You can probably poll the XmlHttpRequest object, so just try to send a heartbeat every once in a while to see if the connection is closed. Otherwise, the server would have to send some signal to tell the client it is going to close the connection.
It does seem that the server cannot notify the client that the connection is closed; however the polling method suggested is not as efficient as a notification would have been.
I solved it by specifying that at the NEXT Get request, the client would be told that its session is invalid.
This was implemented by URL rewriting - appending "jsessionid=[id]" on each request sent by the Javascript functions. the servlet stores the current session id.