Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Socket programming with JS!

Reply
Thread Tools

Socket programming with JS!

 
 
Boomer
Guest
Posts: n/a
 
      09-09-2006
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


 
Reply With Quote
 
 
 
 
Tim Williams
Guest
Posts: n/a
 
      09-09-2006
"Boomer" <(E-Mail Removed)> wrote in message
news:U0GMg.31228$(E-Mail Removed). ..
> 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



 
Reply With Quote
 
 
 
 
Tom Cole
Guest
Posts: n/a
 
      09-10-2006

Tim Williams wrote:
> "Boomer" <(E-Mail Removed)> wrote in message
> news:U0GMg.31228$(E-Mail Removed). ..
> > 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


 
Reply With Quote
 
Boomer
Guest
Posts: n/a
 
      09-10-2006
"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




 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      09-10-2006
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.

 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      09-10-2006
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

 
Reply With Quote
 
sam.partington@gmail.com
Guest
Posts: n/a
 
      09-11-2006
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 1 02-03-2009 06:20 AM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 0 02-01-2009 12:45 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 0 02-01-2009 07:37 AM
socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 1 01-27-2009 05:05 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48,'Address already in use') Jean-Paul Calderone Python 0 01-27-2009 01:41 PM



Advertisments