Real-time server push?

M

Martin

I have web-based user interface for an industrial automation system
that has some pages that display some activity and data in real time.
I have two distinctly different ways of doing this - both of which
have undesireable aspects.

1: I use AJAX - with the browser requesting a refresh once per second.
Since displayable information can be generated at any moment, I have
to buffer it on the server-side and then I have a time-stamp on each
piece of data so the client can tell if it's already displayed a
particular item. This all works ok but the display in the browser
isn't truely "real-time" - several events will appear on the screen at
the same instant even though they actually occurred at slightly
different times.

2: I have page set up that downloads a dll from the server that
contains a client-side socket that, when the page is loaded, connects
to a socket on the server. I then shove data in true real-time from
the server to the client page where it is displayed. All of the
client/page side activity is controlled by VBScript (and DHTML). The
problem here is that this works only with VBScript- and thus works
only in Internet Explorer.

I like the second approach better so, finally my question:

Does anyone know if there is program available anywhere (perhaps a
Java applet) that provides the same functionality as the DLL I'm
currently using but would have the ability to be manipulated by
Javascript? This would allow true real-time display of the data and
would work in all browsers. FWIW, Javascript is already being used on
all of my interface's pages.

Thanks for any recommendations.
 
B

Bart Van der Donck

Martin said:
I have web-based user interface for an industrial automation system
that has some pages that display some activity and data in real time.
I have two distinctly different ways of doing this - both of which
have undesireable aspects.

1: I use AJAX - with the browser requesting a refresh once per second.
Since displayable information can be generated at any moment, I have
to buffer it on the server-side and then I have a time-stamp on each
piece of data so the client can tell if it's already displayed a
particular item. This all works ok but the display in the browser
isn't truely "real-time" - several events will appear on the screen at
the same instant even though they actually occurred at slightly
different times.

2: I have page set up that downloads a dll from the server that
contains a client-side socket that, when the page is loaded, connects
to a socket on the server. I then shove data in true real-time from
the server to the client page where it is displayed. All of the
client/page side activity is controlled by VBScript (and DHTML). The
problem here is that this works only with VBScript- and thus works
only in Internet Explorer.

I like the second approach better so, finally my question:

Does anyone know if there is program available anywhere (perhaps a
Java applet) that provides the same functionality as the DLL I'm
currently using but would have the ability to be manipulated by
Javascript? This would allow true real-time display of the data and
would work in all browsers. FWIW, Javascript is already being used on
all of my interface's pages.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Realtime update</title>
<script type="text/javascript">
var refresh_int = 1000; // milliseconds
function realt() {
frames['r'].location = 'realtime.php?'+(new Date()).getTime();
setTimeout('realt()', refresh_int);
}
</script>
</head>
<body onLoad="realt()">
<iframe name="r"></iframe>
</body>
</html>

If MSIE's loading bar would be annoying, you could execute 'realt()'
in AJAX:

var x = null;
if (window.XMLHttpRequest) {
x = new XMLHttpRequest();
}
else if (window.ActiveXObject) {
x = new ActiveXObject('Microsoft.XMLHTTP');
}
if (x != null) {
x.open('GET', 'realtime.php?'+(new Date()).getTime(), false);
x.send(null);
if (x.readyState == 4 && x.status == 200)
frames['r'].location = 'realtime.php?'+ (new Date()).getTime();
}
setTimeout('realt()', refresh_int);

Hope this helps,
 
D

David Mark

Martin said:
I have web-based user interface for an industrial automation system
that has some pages that display some activity and data in real time.
I have two distinctly different ways of doing this - both of which
have undesireable aspects.
1: I use AJAX - with the browser requesting a refresh once per second.
Since displayable information can be generated at any moment, I have
to buffer it on the server-side and then I have a time-stamp on each
piece of data so the client can tell if it's already displayed a
particular item. This all works ok but the display in the browser
isn't truely "real-time" - several events will appear on the screen at
the same instant even though they actually occurred at slightly
different times.
2: I have page set up that downloads a dll from the server that
contains a client-side socket that, when the page is loaded, connects
to a socket on the server. I then shove data in true real-time from
the server to the client page where it is displayed. All of the
client/page side activity is controlled by VBScript (and DHTML). The
problem here is that this works only with VBScript- and thus works
only in Internet Explorer.
I like the second approach better so, finally my question:
Does anyone know if there is program available anywhere (perhaps a
Java applet) that provides the same functionality as the DLL I'm
currently using but would have the ability to be manipulated by
Javascript? This would allow true real-time display of the data and
would work in all browsers. FWIW, Javascript is already being used on
all of my interface's pages.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/html4/loose.dtd">
<html>
 <head>
  <title>Realtime update</title>
  <script type="text/javascript">
   var refresh_int = 1000; // milliseconds
   function realt()  {
    frames['r'].location = 'realtime.php?'+(new Date()).getTime();
    setTimeout('realt()', refresh_int);
   }
  </script>
 </head>
 <body onLoad="realt()">
   <iframe name="r"></iframe>
 </body>
</html>

If MSIE's loading bar would be annoying, you could execute 'realt()'
in AJAX:

 var x = null;
 if (window.XMLHttpRequest)  {
  x = new XMLHttpRequest();
 }
 else if (window.ActiveXObject)  {
  x = new ActiveXObject('Microsoft.XMLHTTP');
 }
 if (x != null)  {
  x.open('GET', 'realtime.php?'+(new Date()).getTime(), false);
  x.send(null);
  if (x.readyState == 4 && x.status == 200)
   frames['r'].location = 'realtime.php?'+ (new Date()).getTime();
 }
 setTimeout('realt()', refresh_int);

Polling with IFrames or XHR is hardly real time. It's Comet or
nothing these days (at least for JS developers.)
 
J

Jorge

(...)
Polling with IFrames or XHR is hardly real time. It's Comet or
nothing these days (at least for JS developers.)

1.- @the client: establish a comms channel with the server by sending
a request (an xmlHttpRequest), and return.

If/when the server has data to send:

2.- @the server: the server sends real time data through the
connection opened in step 1.
3.- @the client: data received: an onreadyestatechange event happens.
4.- @the client: the onreadyestatechange handler: gosub 1 and
processes the data received in step 3.

If the server has nothing to send:

2.- @the client: the connection established in step 1 will eventually
time out and trigger an onreadystatechange event with status !== 200.
3.- @the client: the onreadyestatechange handler: gosub 1 and return.
 
D

David Mark

1.- @the client: establish a comms channel with the server by sending
a request (an xmlHttpRequest), and return.

If/when the server has data to send:

2.- @the server: the server sends real time data through the
connection opened in step 1.
3.- @the client: data received: an onreadyestatechange event happens.
4.- @the client: the onreadyestatechange handler: gosub 1 and
processes the data received in step 3.

If the server has nothing to send:

2.- @the client: the connection established in step 1 will eventually
time out and trigger an onreadystatechange event with status !== 200.
3.- @the client: the onreadyestatechange handler: gosub 1 and return.

That's the pseudo-code for one transport. It's not the ideal choice
for most cases.
 
D

David Mark

It might not be "ideal", but it works in ~ any browser and doesn't
require VB, Java, Flash nor SilverLight.

Nothing I have recommended requires any of those either. Your pseudo-
code demonstrates the LCD of the remaining choices. And it will not
work in any browser.
 
R

Richard Maher

Hi Martin,

Martin said:
I have web-based user interface for an industrial automation system
that has some pages that display some activity and data in real time.
I have two distinctly different ways of doing this - both of which
have undesireable aspects.

1: I use AJAX - with the browser requesting a refresh once per second.
Since displayable information can be generated at any moment, I have
to buffer it on the server-side and then I have a time-stamp on each
piece of data so the client can tell if it's already displayed a
particular item. This all works ok but the display in the browser
isn't truely "real-time" - several events will appear on the screen at
the same instant even though they actually occurred at slightly
different times.

2: I have page set up that downloads a dll from the server that
contains a client-side socket that, when the page is loaded, connects
to a socket on the server. I then shove data in true real-time from
the server to the client page where it is displayed. All of the
client/page side activity is controlled by VBScript (and DHTML). The
problem here is that this works only with VBScript- and thus works
only in Internet Explorer.

I like the second approach better so, finally my question:

Does anyone know if there is program available anywhere (perhaps a
Java applet) that provides the same functionality as the DLL I'm
currently using but would have the ability to be manipulated by
Javascript? This would allow true real-time display of the data and
would work in all browsers. FWIW, Javascript is already being used on
all of my interface's pages.

Thanks for any recommendations.

If you just want a connection-oriented TCP/IP Java Socket example with one
server thread or process per client, then there are many Java examples on
the web. One such example is: -
http://manson.vistech.net/t3$examples/demo_client_web.html

All Java source code is in:
http://manson.vistech.net/t3$examples/
Warning: That code's a bit old now and optimistic in that it doesn't loop
around until a "complete" message has been read.

But again, personally, I suggest you use Java to create a UDP Socket as
in: -
http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24

You then subscribe to a service using Ajax or TCP/IP and tell them your Port
Number and IP Address. (UDP involves sequence checking, heartbeats, and
duplication detection) When you get an asynchronous message that requires
further action then you once again use the TCP/IP stream (or Ajax) to
perform the normal PULL transaction.Wrap it all up in IPsec and you're good
to go!

Cheers Richard Maher

PS. As mentioned in that thread/discussion, if you are using multicasting
then you can drop the "subscribe" step altogether and just subscribe to the
multicast group in the client. (Sandbox rules and certificates
notwithstanding.)
 
M

Martin

If you just want a connection-oriented TCP/IP Java Socket example with one
server thread or process per client, then there are many Java examples on
the web. One such example is: -
http://manson.vistech.net/t3$examples/demo_client_web.html

Yes, a connection-oriented TCP/IP socket is what I'm looking for. The
link you provided is prompting for a userid and password so I can't
get to whatever is there.

I tried going to: manson.vistech.net but... Yikes, what is that?!
All Java source code is in:
http://manson.vistech.net/t3$examples/
Warning: That code's a bit old now and optimistic in that it doesn't loop
around until a "complete" message has been read.

But again, personally, I suggest you use Java to create a UDP Socket as
in: -
http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24
You then subscribe to a service using Ajax or TCP/IP and tell them your Port
Number and IP Address. (UDP involves sequence checking, heartbeats, and
duplication detection) When you get an asynchronous message that requires
further action then you once again use the TCP/IP stream (or Ajax) to
perform the normal PULL transaction.Wrap it all up in IPsec and you're good
to go!

Cheers Richard Maher

PS. As mentioned in that thread/discussion, if you are using multicasting
then you can drop the "subscribe" step altogether and just subscribe to the
multicast group in the client. (Sandbox rules and certificates
notwithstanding.)

I don't think there's any need for me to get into UDP or multi-casting
and the like.

I did not mention in my original post, but my situation is rather
simple. This user interface system operates only on an inTRAnet (not
on the internet). There will seldom be multiple users accessing pages
simultaneously - and even when that occurs, it would be very unlikely
to have more than 2 or 3 users at a time.

What I think I want is just to have a client-side socket that I can
send out in the page and, in the pageLoad event have it connect back
to a server-side socket. Then have it raise a "dataArrival" event when
data comes in and make the data available such that I can display it
using Javascript.

Another reason I want to stay with the socket concept is that I can
have the client connect directly to my interface process and get it's
data that way. IOW, my server-side scripts don't even need to get
involved with this.
 
R

Richard Maher

Hi Martin,

Martin said:
Yes, a connection-oriented TCP/IP socket is what I'm looking for. The
link you provided is prompting for a userid and password so I can't
get to whatever is there.

If you're still curious use: -
Username: TIER3_DEMO
Password: QUEUE

But there should be a directory listing at the other URL I gave you: -
http://manson.vistech.net/t3$examples/
I tried going to: manson.vistech.net but... Yikes, what is that?!

It's VMS box (a crappy old hobbyists' one but still.) You see long, long ago
in a land far, far away there lived VMS. . .never mind.

You can ignore the server code as it makes no difference, just look at the
..Java, .JS, and .HTML files.
I don't think there's any need for me to get into UDP or multi-casting
and the like.

I did not mention in my original post, but my situation is rather
simple. This user interface system operates only on an inTRAnet (not
on the internet). There will seldom be multiple users accessing pages
simultaneously - and even when that occurs, it would be very unlikely
to have more than 2 or 3 users at a time.

Then I suggest just using iNETD and one process/user and keep it simple.
What I think I want is just to have a client-side socket that I can
send out in the page and, in the pageLoad event have it connect back
to a server-side socket. Then have it raise a "dataArrival" event when
data comes in and make the data available such that I can display it
using Javascript.

For that you'll need a seperate thread in the Applet similar to the one
discussed in: -
http://groups.google.com/group/comp.lang.javascript/msg/49999ef98ab29b24
Just TCP/IP instead of UDP. Heaps of other examples on Google, SUN Tutorials
etc.
Another reason I want to stay with the socket concept is that I can
have the client connect directly to my interface process and get it's
data that way. IOW, my server-side scripts don't even need to get
involved with this.

Sounds good.

Cheers Richard Maher.
 
D

David Mark

That's not polling, meu filho.

If it looks like a duck, walks like a duck and quacks like a duck...
it's probably a duck. You are polling, whether you realize it or not.
 
J

Jorge

If it looks like a duck, walks like a duck and quacks like a duck...
it's probably a duck.  You are polling, whether you realize it or not.

No, there aren't any timers involved there's ~permanently an open
channel through which the server can send the data as-it-happens, in
real time, and that's not the same thing as querying (polling) the
server at regular intervals.
 
J

Jorge

It's not permanent per your pseudo-code.

It can't be, unfortunately, that's why I wrote *almost* :
~permanently. If the slight "blackouts" in-between consecutive xhrs
are troubling you, using a bit of intelligence at the server side
together with a couple of xhrs open in parallel would help to mitigate
the problem completely.

"Polling is sometimes used synonymously with busy-wait polling (Busy
waiting). In this situation, when an I/O operation is required the
computer does nothing other than check the status of the I/O device
until it is ready, at which point the device is accessed. In other
words the computer waits until the device is ready. Polling also
refers to the situation where a device is repeatedly checked for
readiness, and if it is not the computer returns to a different task.
Although not as wasteful of CPU cycles as busy-wait, this is generally
not as efficient as the alternative to polling, interrupt driven I/O."

http://en.wikipedia.org/wiki/Polling_(computer_science)

The I/O in the code I posted isn't polling, it's driven by
(onreadystatechange) event(s), because events are the closest thing to
an interrupt that we have in the JS environment in a browser.

HTH,
 
D

David Mark

It can't be, unfortunately, that's why I wrote *almost* :
~permanently. If the slight "blackouts" in-between consecutive xhrs
are troubling you, using a bit of intelligence at the server side
together with a couple of xhrs open in parallel would help to mitigate
the problem completely.

Nothing you write troubles me.

Dueling Wiki entries? Which is more appropriate for this discussion?
The I/O in the code I posted isn't polling, it's driven by
(onreadystatechange) event(s), because events are the closest thing to
an interrupt that we have in the JS environment in a browser.

Nonsense. It already has a name that includes the word "polling."
Please stop confusing the issue by contradicting that. Thanks.
 
J

Jorge

(..)
Nonsense.  It already has a name that includes the word "polling."
Please stop confusing the issue by contradicting that.  Thanks.

It's easy: you either know what polling is or you don't.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top