We Keep Coding

Can we get the status of Ajax call, like 20% completed?

Am calling an ajax call to validate n number of data.Since it takes lot of time to complete, I thought of showing the user the progress bar or tell that 1/n completed In-order to display that, I should get the status from the controller.Can someone please tell me is there any way to get the status from controller before completing? Or Is there any other better way to implement.

Since ordinary AJAX is a classic request-response you cannot get progress information from the server with the same connection. You have to make a new AJAX call to ask the server for the task progress. This is called a heartbeat pooling technique.
Better solution is to use some kind of persistent connection, for example Websockets. That way server can push a message with progress information to the client over the same connection that initiated the task. Websocket adoption is strong among browsers.

XMLHttpRequest Monitoring progress:
see here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest#Monitoring_progress
more here:
How to get progress from XMLHttpRequest
looks like this is in the standard
https://www.w3.org/TR/progress-events/#firing-events-using-the-progressevent-interface-for-http

Difference between SSE and Ajax Polling in browser doing queries instead of js code

I've read a bit about Server Side Events and it seems to me that the biggest difference between SSE and Ajax Polling is that in latter you're supposed to query server yourself after each response, while with SSE a browser does that for you. Is it correct?
And in terms of server handling, there is almost no difference between SSE and Ajax Polling, with a minor difference of formatting the response in a certain way and including Content-type: text/event-stream header?

As Seabizkit basically said, one method polls the server (as much as it wants), and the other sends messages (when the server decides to send them).
If there was a single update of some data per day, can you see what the difference would be if all clients were checking once per minute, or the server sending the message once to all who have subscribed to the event?
In your question you ask if this is correct: 'the biggest difference between SSE and Ajax Polling is that in latter you're supposed to query server yourself after each response, while with SSE a browser does that for you'. To me this means you've basically asked if the browser is doing the requests for you.
Ajax Polling is asking for data - so you can check to see if it has changed etc. (similar to a web page request) on a timed basis.
An SSE sends a message to all that want to know of the change ONLY when the change has occurred.
Polling is not querying after each response, it is querying as much as you want, when you want (10 times per second if you wish, a 100, a 1,000, whatever you deem fit).
Events occur WHEN something has happened, and subscribers are then notified (hopefully just the once).
Imagine if I wanted to know if my parcel delivery driver will be turning up within the next 30 minutes.
I could call once a minute and ask - I could do this all day long if I wanted, or the driver can just call me and let me know they are 30 minutes away.
You stated in your comment to Seabizkit that client side initiates communication. No it doesn't. It adds an event handler for an event that is available on the server. The communication after that is the server sending a message to the client, be it 5 seconds later, 5 minutes later, or 50 times per second - the client doesn't request again, it has subscribed to the event and will be notified every time it fires.
Please bear in mind that this is a general explanation - not a technical one, because your question was fairly open in asking what the difference is between the two.

In the context of browsers...
The difference is: One Polls and the other responds to an Event(*).
Polling; is started at the browser end.
Make a request... receive response...do something. (usually change the UI)
Polling is expensive (relative to what you are doing!).
Polling is far easier to setup compared to handling server change on the browser.
Server side Events/Changes; is started at the server.
How to notify the browser?
Browsers out of the box have no way to respond to service side changes.
basically the browser has no idea that anything happened on the server.
You are left to handle this on your own.
Luckily library such as SignalR http://signalr.net/
Can be used simplify this a lot for you. But the complexity is still quite high compared to that of simple page with polling.
It requires you to handle socket connections between "clients".
(*) = pinch of salt, technically not worded correctly.
if this doesn't answer your question or you want more info ask.

Is it better to compose multiple AJAX calls parallel or serial?

I'm developing a single-page application, which sends multiple AJAX request to the server.
The system works with polling, because some data-request can take about 10-20minutes to calculate.
client asks server for data
server hands out a job-id
client asks server every few seconds for the result
The polling algorithm lowers the polling frequency over time, stopping at intervals of 10seconds.
But when a client sends different data requests in a short time, he ends up with about 10-20 job-ids and starts polling for all of them.
Is it better to simply do it this way and let the browser handle those requests in parallel or should I schedule every request and serialize them all?
Would it bring performance benefits to serialize them?

If each initial request returns a unique id and each page has a unique user id then you can poll on what information for each request.
In the JSON I would return the results for any completed request, and the current status of those that haven't completed, such as whether it has started being processed, and perhaps a percentage of completion, or how many requests are ahead of that request.
This will simplify the work as you won't be making several polling calls, but just one, getting back a complex result to give feedback to the user the status of each request.
I find it useful to give some information on status for long-running queries otherwise the user may think the request was lost.

Some months ago, I faced performance issues due to multiple ajax calls, but I haven't investigated deeper this topic since then : High latencies loading stores in an ExtJS 4.1 MVC application.

How do you determine exactly when, accounting for network latency, a HTTP request was sent?

I am building an application where it is important to know exactly when a user submitted a request to the server. This is different from the time at which the server received the request, because there is an interval of time -- that is often subject to the vagaries of network traffic and cell reception -- between the moment the user presses submit and the server receives the POST request.
The interaction is through a web browser with JavaScript, so any solution that involves JavaScript is acceptable. I thought about getting current time on the user's computer or smartphone using JavaScript and using that as a timestamp on the submitted request, but that by itself wouldn't be reliable because the clock on the user's computer could be off. Please assume that the clock on the server is accurate.

I don't think it's possible to get an exact value. I think the best you can do is send a very small calibration AJAX request that equivalents the client time with the server time. That's what I've done anyhow.
Edit for elaboration
Basically make an AJAX call to a server endpoint with the client timestamp (clock). As soon as the server receives the client timestamp retrieve and store the server timestamp along with it. At this point you can assume the times are relatively equivalent. You won't know the network overhead, so they will be different; also their clock could be in a different time zone or just "off".
After you have this equivalence you can use the difference of the two times to calibrate any other times from the client:
clientTime0 - serverTime0 = clientServerDelta
(clientTimeX - clentServerDelta) will be about the same in server time as when clientTimeX was recorded.

You could try this:
http://jehiah.cz/a/ntp-for-javascript
to calculate an accurate JavaScript clock, then pass that value with your POST request.

Rest / HTML - If server stops detect if server starts again?

Something I am playing with at the moment is a Rest / HTML page that dynamically updates via JSON calls.
Now in the case that I want this to run on as low a bandwidth as possible.
So if the server is shut down, then booted up again I want the updates to continue again in most cases this works some cases parts of the javascript won't work and it times out.
So what is a low overhead solution to detect that the Server has started up again?
(Looking for good ideas or other methods to do this)
thoughts:
So far I have thought of having a status request but this uses bandwidth again to continually run?
Or how to only run this status request once the server had gone down and stop when its up?

You could use the setInterval function to continuously poll the server for updates. Once a request fails you could enter a so called safe-mode by sending only HEAD requests (and as suggested by #sje397 also increase the timeout interval) to reduce bandwidth and once it succeeds you enter again normal mode and continue with GET/POST.
There are also more exotic things like COMET and Web Sockets in HTML 5 that allow the server to push updates to the client.