javascript help

Never going to happen - requests across networks will always take an undefined amount of time.

that's also assuming that the client has the correct time.  the idea would be to synchonize with the ntp server your using.  The delay can be measured by recording the time before and after the request but there will always be some margin of error.

at least guide me how to send a parameter along with json url and get its value back.

$.getJSON("http://json-time.appspot.com/time.json?callback=?", function(data){
    document.write(data["hour"]+":"+data["minute"]+":"+data["second"]);
    
});

Select allOpen in new window

i want to data parameter along with json url  

http://json-time.appspot.com/time.json?callback=time()

and i want the time var back to me as hour,minute,second.

function time(){
return (new Date()).getTime()
{
$.getJSON("http://json-time.appspot.com/time.json?callback="+time(), function(data){
    document.write(data["hour"]+":"+data["minute"]+":"+data["second"]);
    
});

Select allOpen in new window

how to get that time() back to me after passing with json url ?

you don't need to do that, if i understand correctly.  you want to know what time you submitted the request and compare it with what comes back?

@tagit  yes.i want to know the what time submitted the request and compare it with what comes back.

To get the time returned from your json call, you need something like this:

$.getJSON("http://json-time.appspot.com/time.json?callback=?", function(data){
	var time = data.hour + ":" + data.minute + ":" + data.second;
});

Select allOpen in new window

If you want to take it one step further, here's how you'd work out the different between two dates (in milliseconds):

$.getJSON("http://json-time.appspot.com/time.json?callback=?", function(data){
	var returnedDate = new Date(data.datetime);
	var now = new Date();
	var difference = now.getTime() - returnedDate.getTime();
	alert(difference);
});

Select allOpen in new window

the time of the submitted request is the clients time not the servers.  The server time is the result you get back.  you would need to sync the clients machine with the ntp to get this remotely accurate.  

going back to what I said before you could determine the delay between the request and the response but that's assuming that the client has sync'd with the server, otherwise you'll still have the error of them being out of sync

So in other words it can't be done accurately, without first making sure the client's time is correct

is there any solution to calculate exact delay  when we have total roundtrip time,server time,request time,response time ?

You can calculate the delay based on the clients time as it is the difference between the time the client initiated the request and time the client received the request

In other words nothing to do with the server time. You could guess that half the delay happened before the server responded so you could get the client and server times very close but never exactly the same in this environment. Most if the time people are happy with it to be this close ;-)

assuming roundtrip delay  as half in both ways always returns  0-500 ms error.

Is there any way to exactly find delay in any way.

ex:  round trip delay = 973  ms

A = server time - request time = 1386 ms

B = response time - server time = -473 ms


I wonder there is a way to find delay in A or B.

Not in this environment. If the server could tell you when it received your request etc that would be a different story.
Can't be done this way...sorry

Please see this   http://yahoo.github.io/boomerang/doc/howtos/howto-3.html

Sure, i saw that.  Second paragraph confirms it:

First, bandwidth detection through javascsript is not accurate. If the user's network is lossy or is shared with other users, or network traffic is bursty, real bandwidth can vary over time. The measurement we take is based over a short period of time, and this may not be representative of the best or worst cases. We try to cover for that by measuring not just the bandwidth, but also the error value in that measurement.

As I said before you'll get it close but never exact, but nothing ever is.  I would accept this as the case that it's the closest you'll get.