By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,480 Members | 1,808 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,480 IT Pros & Developers. It's quick & easy.

Socket programming with JS!

P: n/a
Hello,

Is it possible to live-capture data with JS? The XMLHttpRequest() method is
not really suitable for live data capture.

Any hints/directions?

TIA

Boomer
Sep 9 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"Boomer" <bo******@hotmail.comwrote in message
news:U0*******************@bignews3.bellsouth.net. ..
Hello,

Is it possible to live-capture data with JS? The XMLHttpRequest() method
is not really suitable for live data capture.

Any hints/directions?

TIA

Boomer
In what context ? js has no "native" file/stream functionality, so maybe
there are existing objects which you could script to achieve your aim...

Tim

Sep 9 '06 #2

P: n/a

Tim Williams wrote:
"Boomer" <bo******@hotmail.comwrote in message
news:U0*******************@bignews3.bellsouth.net. ..
Hello,

Is it possible to live-capture data with JS? The XMLHttpRequest() method
is not really suitable for live data capture.
To be honest, HTTP itself isn't really suitable for live data capture.
The whole request, response thing, you know.....

Any reason you couldn't use XmlHttpRequest with a timer?

Any hints/directions?

TIA

Boomer

In what context ? js has no "native" file/stream functionality, so maybe
there are existing objects which you could script to achieve your aim...

Tim
Sep 9 '06 #3

P: n/a
"Any reason you couldn't use XmlHttpRequest with a timer?"

The data is somewhat unpredictable and in many case repetitious. There is no
way of knowing the data that is being captured is old or new when using
XMLHttpRequest().

Thanks for all your comments.

Boomer


Sep 10 '06 #4

P: n/a
VK
Boomer wrote:
The data is somewhat unpredictable and in many case repetitious. There is no
way of knowing the data that is being captured is old or new when using
XMLHttpRequest().
XMLHttpRequest is simply a "virtual browser" (with very harrow
functionality) programmatically created inside the real one. This way
old data/new data question must be solved by the regular Web browsing
means: by setting and checking cache-related headers. It can be also
HEAD request made before GET/POST to see if you need to make new data
request.
If you are thinking of a socket listener, so you would get automated
server notification on new data ready - then HTTP doesn't deal with
such things. Respectively a web-browser has nothing to offer on this
matter.

Sep 10 '06 #5

P: n/a
Boomer wrote:
Is it possible to live-capture data with JS? The XMLHttpRequest() method is
not really suitable for live data capture.
Though its name suggests the opposite, XMLHttpRequest() can be used to
fetch non-XML data as well. And the connection doesn't need to point
to the 'default' http daemon as well; e.g. http://12.34.56.789:585
should take you to port 585 instead of (common) 80.

But the service must accept HTTP-style socket communication anyhow if
you want to connect from a javascript client.

--
Bart

Sep 10 '06 #6

P: n/a
Boomer wrote:
The data is somewhat unpredictable and in many case repetitious. There is no
way of knowing the data that is being captured is old or new when using
XMLHttpRequest().
One solution to this is to have a sequence number that is incremented
on each request. The server keeps track of changes in status, and
remembers the current sequence number t, and sends that sequence number
with each request. When the client issues a request it sends the last
sequence number it received u, the server sends any changes in the data
between u and t.

It requires a somewhat complex state machine running on the server, but
the client side is easy enough.

Typically you would put a limit on the age of sequence numbers, if the
client sends one that is too old the server sends a 'keyframe' that
includes all data, allowing the client to reset everything to the
current status.

The system is still poll driven rather than interrupt driven, but
signifcantly reduces the traffic volume. (And it sounds like that is a
goal in your case).

HTH

Sam

Sep 11 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.