persistent TCP connection over page reloads ?
in [JavaScript]
|
From: mel on 15 Apr 2008 01:19 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.
From: Stevo on 15 Apr 2008 04:36 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.
From: Thomas 'PointedEars' Lahn on 15 Apr 2008 17:51 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
From: mel on 15 Apr 2008 22:08 On Apr 15, 2:51 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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
From: Thomas 'PointedEars' Lahn on 16 Apr 2008 04:58 mel wrote: > On Apr 15, 2:51 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > 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>
|
Next
|
Last
Pages: 1 2 Prev: innerHTML not being recognized in FireFox Next: binding selector/property together |