Hi.
This is not homework. Its an assignment at my internship, and I’ve been appointed a task I haven’t tried before. I have to send an AJAX call from a server machine, and then fetch it and use an integer in that AJAX call to change a variable, in a Javascript running in a browser on the client.
I’ve never done AJAX calls through a local area network before. How would I go about it?
Not much different than you would do on the internet. The Server has to run some kind of Web-Server that can accept and process requests that you send to it. So instead of sending the AJAX Request to a certain homepage you prepare your Webpage (or whatever you want) to send it to the IP-Adress of that Server.
Is there something specific you want to know about?
Edit: Re-read your post. Do you mean to send an AJAX response to the client without a foregoing request of that client?
exactly. You simply connect to the IP. Or if you wish to access the server by name, you can link an alias to IP in the hosts file and then access the server by this alias.
AJAX is no different than normal HTTP, it’s only issued asynchronously by the client. If you want your server to talk back to the client, you have to hold the connection open, until there is a message from the server. But still the connection is issued by the client, see http://en.wikipedia.org/wiki/Comet_(programming) .
Or simply use WebSockets (HTML5) if allowed.
Yes, without the client requesting it. Basically the client should change a number shown on a screen by a full-screen webbrowser, whenever it recieves a specified AJAX call with a value in it.
I intend to do some handshaking first, obviously. So the client connects to the server, and keeps the connection open, receiving AJAX calls at random, while the client continues to update the number on the screen to the last AJAX call received.
Sry for late answer. Processing input form a server without a request is something that is not yet widely supported by current browsers. You could do something like a heartbeat-system where you let the client send a request every 30 seconds or so to the server that answers the number you would like to change.
It is (or has been) however afaik disregarded as bad practice because of the additional traffic that such requests cause. In your case though that would not matter because it is only LAN and only one single number that gets updated.
Another approach is a very long Request that stays open until a certain “Event” causes the Server to respond. After that the Client immediately sends another request, again waiting for the server to respond.
Wikipedia-Article :point:
Also google spits out tons of information on that subject. Including some ready-to-use frameworks that use those approaches:
Hope it helps 
Actually, short polling tends to be more scalable, because long polling holds a socket open longer on the server, and fds are a more scarce resource than bandwidth.
Not that it’s likely to matter that much on a LAN scale.
As sproingie said, considering that you want to implement this in a LAN environment it doesn’t matter much which option you choose.
What you might think about though is that with the first method (polling every x seconds) you have a chance of the client having the wrong number for quite some time (bit less than x seconds in the worst case). Using the second method you have the new number on the client always only short time after the server has the new number (since it’s the server that can then complete request whenever he wants - e.g. when he has a new number to send)
Hi guys.
Thanks for the inspiring thoughts. I ended up doing something…alternative.
Seeing as this project is terribly limited (I have to choose 1 browser to work with, it has to be under Windows, and all information, connections and code must be available directly through the browser, with little to no load-time on any Internet connection), I ended up creating and embedding a small Java applet, which simply holds a ServerSocket running, and whenever we send it a message via LAN, it requests the remote server for the queue-number, and sends it to the JavaScript, which can then use it to draw the new number. Using a bit of concurrency trickery on the server, I should never be without the right number on the screen for more than a few ms.
I realize there are ways to get around the spiderweb of “origin policy”, but this seemed the most unintrusive way to me. At least I’m not going to violate any security protocols in any browsers anymore, and applets are already fully allowed on the client-PCs.
The applet trick is something I did before there was ever such a thing as “AJAX”. I coulda invented web 2.0, but a) I’m sure thousands of others had the same idea, and b) I wasn’t any good at swindling the VCs who were already pulling out right before the dotcom crash. 
Oddly enough, since LiveConnect was so awful, my first demo prototype used a flash 5.0 applet for the socket instead of java.
So the applet-thing is a tried and true, but sort of old-school solution, then?
“Tried”, yes. “True” would imply that it worked at all well, which as my experience showed, was not the case.
Hmm…I’ll keep that in mind, thanks. It seems to be working fine for my small project here at the moment, though. It’ll only ever communicate with 2 computers anyway. 1 LAN and 1 server.