persistent TCP connection over page reloads ?

[mel]

Hi all,

I need a persistent TCP connection with my web server over page
reloads.

This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

I know I can do something similar with globalStorage in FF,
window.name & userData on IE, but those storages only hold strings.
And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

I wonder if anyone knows if this is possible at all.

Sam

PS it doesn't have to be only in javascript. the solution can
use flash too.

[Stevo]

mel wrote:

I need a persistent TCP connection with my web server over page
reloads.

This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

I wonder if anyone knows if this is possible at all.

Sam

PS it doesn't have to be only in javascript. the solution can
use flash too.

I vaguely recall this being possible with a Java Applet. Although I've
done plenty of Java, I've never dabbled with applets so I can't confirm
if this is true. Somebody who seemed to know what he was talking about
told me such things were possible. It's worth at least asking the same
question on a Java forum.

[Thomas 'PointedEars' Lahn]

mel wrote:

I need a persistent TCP connection with my web server over page
reloads.

No, you don't. Besides, persistent *HTTP* connections (which is what you
mean) have to be supported by both client and server, and they won't help
you here. Whether the HTTP connection is persistent or not, the current
global execution context of the script engine is destructed when another
resource is being navigated to.

This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

Chances are that it is kept alive already, as persistent connections are the
HTTP/1.1 default. You don't seem to know what TCP is.

I know I can do something similar with globalStorage in FF,
window.name & userData on IE,

Or simply cookies, supported by all scriptable UAs through the same mechanism.

but those storages only hold strings.

What else would you want to store? Even an image can be represented by a
sequence of characters.

And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

But you can serialize objects.

I wonder if anyone knows if this is possible at all.

That depends on what you are *really* up to.

PS it doesn't have to be only in javascript. the solution can
use flash too.

comp.lang.misc would have been the appropriate newsgroup then.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[mel]

On Apr 15, 2:51 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

mel wrote:

I need a persistent TCP connection with my web server over page
reloads.

No, you don't. Besides, persistent *HTTP* connections (which is what you
mean) have to be supported by both client and server, and they won't help
you here. Whether the HTTP connection is persistent or not, the current

wait. aren't HTTP connections built on top of TCP ?

global execution context of the script engine is destructed when another
resource is being navigated to.

window.name & globalStorage & userData aren't destructed

This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

Chances are that it is kept alive already, as persistent connections are the
HTTP/1.1 default. You don't seem to know what TCP is.

You don't seem to understand my question.

>

I know I can do something similar with globalStorage in FF,
window.name & userData on IE,

Or simply cookies, supported by all scriptable UAs through the same mechanism.

cookies go back to the web server. i don't want them to. cookies only
store strings, which doesn't work for me either (unless I can
serialize a xmlhttprequest).

but those storages only hold strings.

What else would you want to store? Even an image can be represented by a
sequence of characters.

A XmlHttpRequest can't.

I want to store a XMLHttpRequest object and not destruct it over page
reloads.

Actually, it doesn't have to be a XMLHttpRequest, that is why I didn't
mentioned HTTP.

As far as the connection is alive over page reloads, it works for me.

It could be a ftp session, or any other kind of connection through js,
java applets, flash or whatever other technology you want to use (as
Stevo pointed out).

And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

But you can serialize objects.

I wonder if anyone knows if this is possible at all.

That depends on what you are *really* up to.

maybe you didn't understand what I need.

I need to keep a connection with my server over page reloads (doesn't
have to be a webserver talking HTTP, could be anything. it is just
that is easier to make a HTTP connection to a webserver in JS, but
with flash or applets u could have any other kind like ftp, XMPP, a
plain TCP connection, etc).

I want to stream data from the server to the client (I guess this is
called push, reversed ajax, or watever), but once the streaming starts
my server can't loose the connection with the client (the browser).

any ideas ?

>

PS it doesn't have to be only in javascript. the solution can
use flash too.

comp.lang.misc would have been the appropriate newsgroup then.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Thomas 'PointedEars' Lahn]

mel wrote:

On Apr 15, 2:51 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>mel wrote:

>> I need a persistent TCP connection with my web server over page
reloads.

No, you don't. Besides, persistent *HTTP* connections (which is what you
mean) have to be supported by both client and server, and they won't help
you here. Whether the HTTP connection is persistent or not, the current

wait. aren't HTTP connections built on top of TCP ?

Yes, they are. But that does not matter.

>global execution context of the script engine is destructed when another
resource is being navigated to.

window.name & globalStorage & userData aren't destructed

As for window.name, there is insufficient proof for that.

>> This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

Chances are that it is kept alive already, as persistent connections are the
HTTP/1.1 default. You don't seem to know what TCP is.

You don't seem to understand my question.

You don't seem to have asked the right one.

>> I know I can do something similar with globalStorage in FF,
window.name & userData on IE,

Or simply cookies, supported by all scriptable UAs through the same mechanism.

cookies go back to the web server.

Cookies are stored client-side. They are submitted to the Web server only
on request.

i don't want them to. cookies only store strings, which doesn't work for
me either (unless I can serialize a xmlhttprequest).

>>but those storages only hold strings.

What else would you want to store? Even an image can be represented by a
sequence of characters.

A XmlHttpRequest can't.

Yes, it can. Reading it back is the difficult thing.

I want to store a XMLHttpRequest object and not destruct it over page
reloads.

Tough luck. You will need a persistent container object for your persistent
execution context, say a frame or another window.

Actually, it doesn't have to be a XMLHttpRequest, that is why I didn't
mentioned HTTP.

I beg your pardon?

As far as the connection is alive over page reloads, it works for me.

That depends on what you call a "page".

It could be a ftp session, or any other kind of connection through js,
java applets, flash or whatever other technology you want to use (as
Stevo pointed out).

ISTM you don't want to use browser scripting.

>>And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

But you can serialize objects.

>> I wonder if anyone knows if this is possible at all.

That depends on what you are *really* up to.

maybe you didn't understand what I need.

Maybe you have not explained it properly.

[...]
I want to stream data from the server to the client (I guess this is
called push, reversed ajax, or watever), but once the streaming starts
my server can't loose the connection with the client (the browser).

any ideas ?

You have explained what you want but not why. ISTM you are on the wrong
track, and in the wrong newsgroup anyway.
Please trim your quotes.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[beegee]

On Apr 15, 1:19*am, mel <[e-mail]:

Hi all,

* * * *I need a persistent TCP connection with my web server over page
reloads.

* * * *This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

* * * * I know I can do something similar with globalStorage in FF,
window.name & userData on IE, but those storages only hold strings.
And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

* * * * I wonder if anyone knows if this is possible at all.

* * * * Sam

* * * * PS it doesn't have to be only in javascript. the solution can
use flash too.

You could do it with Flash.

1. Write your own little Flash server (there are a lot of open source
examples in Java and Python) that keeps a connection open and has
someway to identify client connections.
2. Write a Flash HTTP connection client object that stores and reads a
connection identifier from a cookie.

I know its a lot of work and a radical approach but I can't think of
another way. From my point of view, anything is better than dealing
with Java applets.

Bob

[mel]

On Apr 16, 1:58 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

mel wrote:

On Apr 15, 2:51 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

mel wrote:
I need a persistent TCP connection with my web server over page
reloads.
No, you don't. Besides, persistent *HTTP* connections (which is what you
mean) have to be supported by both client and server, and they won't help
you here. Whether the HTTP connection is persistent or not, the current

wait. aren't HTTP connections built on top of TCP ?

Yes, they are. But that does not matter.

global execution context of the script engine is destructed when another
resource is being navigated to.

window.name & globalStorage & userData aren't destructed

As for window.name, there is insufficient proof for that.

> This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.
Chances are that it is kept alive already, as persistent connections are the
HTTP/1.1 default. You don't seem to know what TCP is.

You don't seem to understand my question.

You don't seem to have asked the right one.

> I know I can do something similar with globalStorage in FF,
window.name & userData on IE,
Or simply cookies, supported by all scriptable UAs through the same mechanism.

cookies go back to the web server.

Cookies are stored client-side. They are submitted to the Web server only
on request.

i don't want them to. cookies only store strings, which doesn't work for
me either (unless I can serialize a xmlhttprequest).

>but those storages only hold strings.
What else would you want to store? Even an image can be represented by a
sequence of characters.

A XmlHttpRequest can't.

Yes, it can. Reading it back is the difficult thing.

not difficult, impossible. serializing it would make it a string, and
when the object reference is lot, it will close the http connection.

deserializing it wouldn't get the object to its original state.

or am I wrong ?

>

I want to store a XMLHttpRequest object and not destruct it over page
reloads.

Tough luck. You will need a persistent container object for your persistent
execution context, say a frame or another window.

that is one solution (doing everything inside a frame or opening
another window), but (1) i don't want to put my hole website inside a
frame, and (2) I am trying to avoid popups (because no one likes
popups, and most of the people disables them).

Actually, it doesn't have to be a XMLHttpRequest, that is why I didn't
mentioned HTTP.

I beg your pardon?

As far as the connection is alive over page reloads, it works for me.

That depends on what you call a "page".

A page, contained inside a <htmltag. If a page gets reloaded, is
there a way to keep a connection with the server live ?

It could be a ftp session, or any other kind of connection through js,
java applets, flash or whatever other technology you want to use (as
Stevo pointed out).

ISTM you don't want to use browser scripting.

I do. I woulde definitely prefer to use js.

But if js can't do the job, then I am flexible enough to go to a
different approach.

>

>And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).
But you can serialize objects.

> I wonder if anyone knows if this is possible at all.
That depends on what you are *really* up to.

maybe you didn't understand what I need.

Maybe you have not explained it properly.

[...]
I want to stream data from the server to the client (I guess this is
called push, reversed ajax, or watever), but once the streaming starts
my server can't loose the connection with the client (the browser).

any ideas ?

You have explained what you want but not why. ISTM you are on the wrong
track, and in the wrong newsgroup anyway.

I guess I am not in the wrong newsgroup, since this questions if
javascript is capable of doing something or not.

The why is here:

I have a server, and it streams data to a particular user. It is
important for me to keep the connection with the user live, even if
the user goes to a different page (inside my domain). I am not using
frames, and I don't want to popup another window to keep this
connection live.

Couple of things I tried:

1) serializing/deserializing the XMLhttpRequest & storing it on the
globalStorage & userData (this is very unlikely to work, because it is
kind of absurd)
2) setTimeout(function() {return obj}, 5 seconds ) on unload() and
catching it back on load() (this is very unlikely to work, because it
is absurd)
3) keeping the connection live on the browser's visited page, and
access it through the current page (this doesn't work either)
4) putting all my site inside a frame, and using a 0size frame with
the object (that works, but makes everything ugly)
5) opening a popup window and keeping the object there (that works
too, but oppup blockers block me)

those are all kind of absurd, but I had to try.

Please trim your quotes.

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[mel]

On Apr 16, 7:26 am, beegee <[e-mail]:

On Apr 15, 1:19 am, mel <[e-mail]:

Hi all,

I need a persistent TCP connection with my web server over page
reloads.

This means that, even if the user goes to a different page (in
my domain), I want to keep a TCP connection live.

I know I can do something similar with globalStorage in FF,
window.name & userData on IE, but those storages only hold strings.
And, AFAIK, I can't serialize a TCP connection (could be through
XmlHttpRequest, etc).

I wonder if anyone knows if this is possible at all.

Sam

PS it doesn't have to be only in javascript. the solution can
use flash too.

You could do it with Flash.

1. Write your own little Flash server (there are a lot of open source
examples in Java and Python) that keeps a connection open and has
someway to identify client connections.
2. Write a Flash HTTP connection client object that stores and reads a
connection identifier from a cookie.

I know its a lot of work and a radical approach but I can't think of
another way. From my point of view, anything is better than dealing
with Java applets.

Bob

That is kind of solving the problem on the server side. I was hoping
for something on the client side.

But you understood what I am trying to solve here ...

Is there a way to keep a live connection on a flash client (even if
the user unloads the flash from the browser) ?

[beegee]

On Apr 16, 7:42*pm, mel <[e-mail]:

Is there a way to keep a live connection on a flash client (even if
the user unloads the flash from the browser) ?

No, you need a server that will keep open the connection. Google
"Comet".

Bob

[Thomas 'PointedEars' Lahn]

mel wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

>mel wrote:

>>>>but those storages only hold strings.
What else would you want to store? Even an image can be represented by a
sequence of characters.
A XmlHttpRequest can't.

Yes, it can. Reading it back is the difficult thing.

not difficult, impossible. serializing it would make it a string, and
when the object reference is lot, it will close the http connection.

deserializing it wouldn't get the object to its original state.

or am I wrong ?

I think it would be possible to restore the status and the data already
received, but the request would have to be a new one.

>>I want to store a XMLHttpRequest object and not destruct it over page
reloads.

Tough luck. You will need a persistent container object for your persistent
execution context, say a frame or another window.

that is one solution (doing everything inside a frame or opening
another window), but (1) i don't want to put my hole website inside a
frame, and (2) I am trying to avoid popups (because no one likes
popups, and most of the people disables them).

Without serialization, it is the only solution with browser scripting.

>>Actually, it doesn't have to be a XMLHttpRequest, that is why I didn't
mentioned HTTP.

I beg your pardon?

>>As far as the connection is alive over page reloads, it works for me.

That depends on what you call a "page".

A page, contained inside a <htmltag.

You mean an HTML document.

If a page gets reloaded, is there a way to keep a connection with the
server live ?

The connection: yes (see HTTP/1.1). The global execution context: no.

>>It could be a ftp session, or any other kind of connection through js,
java applets, flash or whatever other technology you want to use (as
Stevo pointed out).

ISTM you don't want to use browser scripting.

I do. I woulde definitely prefer to use js.

But if js can't do the job, then I am flexible enough to go to a
different approach.

Again, then you should ask in the appropriate newsgroup. Maybe not
comp.lang.misc but comp.infosystems.www.authoring.misc as this is more
about technique than language.

I guess I am not in the wrong newsgroup, since this questions if
javascript is capable of doing something or not.

"javascript" is capable of a great many things that are not particularly
on-topic here because "javascript" is primarily used as an interfacing
programming language.

The why is here:

I have a server, and it streams data to a particular user. It is
important for me to keep the connection with the user live, even if
the user goes to a different page (inside my domain). I am not using
frames, and I don't want to popup another window to keep this
connection live.

Tough luck.

Couple of things I tried:

1) serializing/deserializing the XMLhttpRequest & storing it on the
globalStorage & userData (this is very unlikely to work, because it is
kind of absurd)

I think it could work, but it would not be very efficient.

2) setTimeout(function() {return obj}, 5 seconds ) on unload() and
catching it back on load() (this is very unlikely to work, because it
is absurd)

It cannot work because setTimeout() is a method of a Window object that is
referred to be the `window' property of the Global Object of the global
execution context. That context is destructed on navigation.

3) keeping the connection live on the browser's visited page, and
access it through the current page (this doesn't work either)

Same reason.

4) putting all my site inside a frame, and using a 0size frame with
the object (that works, but makes everything ugly)

Same reason. No navigation in that frame, no destruction of the global
execution context associated with it.

5) opening a popup window and keeping the object there (that works
too, but oppup blockers block me)

See above.

[...]

>Please trim your quotes.

Which part of that did you not get?

http://www.jibbering.com/faq/faq_notes/clj_posts.html
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>