Best strategy for Applets, Sockets, Frames, Destroy(), isConnected() and more . . .

[Richard Maher]

Hi,

[Please point me to the correct forum if this isn't it, otherwise please
help if you can.]

Let me start by stating the basic requirement: - In a browser environment, I
wish to connect to a server (other than the html webserver that is hosting
the page) via a TCP/IP socket and exchange messages when and as needs be
but, once established, keep the connection open to the server until the
browser instance is shutdown. Ideally, I think I'm looking for something
that can work with html -> Javascript -> Java Applet. The user must ne free
to jump from page to page and tab to tab while the network connection lives.

Solution 1. Java Applet - Init() and Destroy()

Use the Init() method to create the socket and connect to the server and the
Destroy() method to close the socket. This seemed to be a perfect match to
my requirements! Until someone pointed out to me that almost all (see list
below) browsers call the Destroy() method whenever a new page is displayed
:-( This is *totally* at odds with all documentation I've seen for the
Destroy() method. What is the difference between Stop() and Destroy() if the
latter is called at *every* page change. Is it only 'cos I'm *not* using a
seperate thread for the Applet? Is there a Browser setting that controls
this?

Solution 2. Java Applet - Init() and never close.

If I ignore Destroy() altogether and simply stick a "if not
mysocket.isConnected() then" in the Init() method, and never *explicitly*
close the socket then that should work shouldn't it?

Two questions (at least) immediately spring to mind: -

(a) Will the Socket *ever* get closed (even when the browser is closed) and
the JVM collect the garbage, or will it simply leak resources until the
client runs out of sockets or memory?

(b) If the page and/or Applet is reloaded will the memory containing the
Socket structure be reinitialized and a false negative be returned to
isConnected() even though the other socket is still there?
Public/Private/Static/Session Variables needed?

Solution 3. Frames

Put the Applet in a seperate (possibly invisible) frame that is never
changed and therefore the Destroy() is never called until browser exit?

Solution BEST. *Please* tell me!

Surely this is not rocket science? I simply wish to fire up a page which
loads an applet, connect to the server, and keep that connection up and
ready for action no matter what the user does (short of closing the
browser). I simply cannot be Christopher Columbus here! Please advise how
best to achieve this functionality.

I'm not great with Java or OO code in general but for a complete discussion
of what I'm attempting you can look at the following thread: -
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1071300

Thanks!

Cheers Richard Maher

PS. Please *don't* discuss AJAX or Java Web-Start or your personal favourite
way of doing things. I know enough (barely to know that my request is
both reasonable and valid; please try to anser *the question*.

List of browsers that call Destroy prematurely: -

Browser Platform Version Comment
Firefox Linux 1.5.0.8 calls destroy when change page
Netscape Linux 7.1 (very old version) calls destroy when change page
Konqueror Linux 3.0.3-13 (very old version) does not call destroy but the
page does not work!
Opera Linux 6.1 (very old version) crash!
Explorer XP 6.0 calls destroy when change page, the page does not work due
an javascript error
Opera XP 8.51 does not work due security

 

[Andrew Thompson]

Richard Maher wrote:
....

Let me start by stating the basic requirement: - In a browser environment,

Huh? Does that mean 'in a browser'?

The reason I ask is that if that is an absolute and
non-negotiable requirement, it is unlikely that any
level of control or reliability can be attained.
(..as some of your own text indicated you were
aware of at least some of the problems of
browser/applet/VM interaction)

Surely this is not rocket science?

No, it's more a matter of lack of organisation on Sun's part.

I think thay are mostly embarrassed by applets, and wishing
people would forget them. As a result, Sun seems not
to want to push makers of browsers to ensure there is a
reliable and predictable environment in which applets
can run.

But you might always look to..

PS. Please *don't* discuss AJAX or Java Web-Start or your personal favourite
way of doing things. I know enough (barely to know that my request is
both reasonable and valid; please try to anser *the question*.

...oh, well in that case, I have nothing further to add.

Good luck with that.

Andrew T.

 

[Richard Maher]

Hi Andrew,

Somewhere in there amongst your bias-laden angst and scintillating rendition
of Right-Said-Fred's "I'm too sexy for my shirt!", I got the impression that
you were claiming that Sun thinks Applets are crap, should be deprecated,
and no one in the world is using them. Do you have any facts or
documentation references to back up these claims or have I simply
mis-understood you?

All I wish to do is keep a tcp/ip socket connection to a server open when a
page-change occurs. To me, this seems like a reasonable thing to do; in
fact, as reasonable as wishing to keep a thread running after a similar
event. Now if this functionality is completely unobtainable in a browser via
Applets then we'll have to learn to live with it, but I wouldn't mind some
sort of pointer to the documentation about it. All of the Sun documentation
that I've seen says that it's not only doable but fully supported
functionality.

I'm new here and don't recognize any names, so Andrew Thompson could well be
the resident Applet Guru (in which case I humbly apologize for having the
impertinence to question his drivel) but I'd really appreciate hearing from
a couple of other independent (and slightly more simpathetic) voices on the
issue.

Regards Richard Maher

PS. What a wonderfully helpful, friendly and informative group this is.

 

[Andrew Thompson]

Richard Maher wrote:
....
(Please refrain from top-posting in future)

Somewhere in there amongst your bias-laden angst and scintillating rendition
of Right-Said-Fred's "I'm too sexy for my shirt!",

Cool tune - # 9284 in my playlist, as it happens.

...I got the impression that
you were claiming that Sun thinks Applets are crap, should be deprecated,
and no one in the world is using them.

Then either you did not read it carefully, or misunderstood
what I was saying.

...Do you have any facts or
documentation references to back up these claims or have I simply
mis-understood you? .....

Look cloesly at the words 'think' and 'seems' and try
answering your own question.

I'm new here and don't recognize any names, so Andrew Thompson could well be
the resident Applet Guru

There are at least 3-4 people on this group who's advice
I would value in regard to applets.

...(in which case I humbly apologize for having the
impertinence to question his drivel)

<dismissive>
Baaaah!

PS. What a wonderfully helpful, friendly and informative group this is.

Part of the 'helpful and informative' comes from the quality
of the questions.. (this is not a help-desk, in case you
have any 'misunderstandings'). For 'friendly' or 'nice' see
comp.lang.java.help.

Andrew T.

 

[Jacob]

I'm new here and don't recognize any names, so Andrew Thompson could well be
the resident Applet Guru

Andrew Thompson is a troll and is best ignored.

 

[Richard Maher]

Hi Jacob,

Thanks for the reply.

Andrew Thompson is a troll and is best ignored.

Fair enough, thanks for the heads-up, but you couldn't take a few minutes to
take a stab at my original question could you?

That is, "How can I best manage a tcp/ip socket network connection so that
it can persist during page changes".

Regards Richard Maher

Complete original question follows: -

Let me start by stating the basic requirement: - In a browser environment, I
wish to connect to a server (other than the html webserver that is hosting
the page) via a TCP/IP socket and exchange messages when and as needs be
but, once established, keep the connection open to the server until the
browser instance is shutdown. Ideally, I think I'm looking for something
that can work with html -> Javascript -> Java Applet. The user must ne free
to jump from page to page and tab to tab while the network connection lives.

Solution 1. Java Applet - Init() and Destroy()

Use the Init() method to create the socket and connect to the server and the
Destroy() method to close the socket. This seemed to be a perfect match to
my requirements! Until someone pointed out to me that almost all (see list
below) browsers call the Destroy() method whenever a new page is displayed
:-( This is *totally* at odds with all documentation I've seen for the
Destroy() method. What is the difference between Stop() and Destroy() if the
latter is called at *every* page change. Is it only 'cos I'm *not* using a
seperate thread for the Applet? Is there a Browser setting that controls
this?

Solution 2. Java Applet - Init() and never close.

If I ignore Destroy() altogether and simply stick a "if not
mysocket.isConnected() then" in the Init() method, and never *explicitly*
close the socket then that should work shouldn't it?

Two questions (at least) immediately spring to mind: -

(a) Will the Socket *ever* get closed (even when the browser is closed) and
the JVM collect the garbage, or will it simply leak resources until the
client runs out of sockets or memory?

(b) If the page and/or Applet is reloaded will the memory containing the
Socket structure be reinitialized and a false negative be returned to
isConnected() even though the other socket is still there?
Public/Private/Static/Session Variables needed?

Solution 3. Frames

Put the Applet in a seperate (possibly invisible) frame that is never
changed and therefore the Destroy() is never called until browser exit?

Solution BEST. *Please* tell me!

Surely this is not rocket science? I simply wish to fire up a page which
loads an applet, connect to the server, and keep that connection up and
ready for action no matter what the user does (short of closing the
browser). I simply cannot be Christopher Columbus here! Please advise how
best to achieve this functionality.

I'm not great with Java or OO code in general but for a complete discussion
of what I'm attempting you can look at the following thread: -
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1071300

Thanks!

Cheers Richard Maher

PS. Please *don't* discuss AJAX or Java Web-Start or your personal favourite
way of doing things. I know enough (barely to know that my request is
both reasonable and valid; please try to anser *the question*.

List of browsers that call Destroy prematurely: -

Browser Platform Version Comment
Firefox Linux 1.5.0.8 calls destroy when change page
Netscape Linux 7.1 (very old version) calls destroy when change page
Konqueror Linux 3.0.3-13 (very old version) does not call destroy but the
page does not work!
Opera Linux 6.1 (very old version) crash!
Explorer XP 6.0 calls destroy when change page, the page does not work due
an javascript error
Opera XP 8.51 does not work due security

 

[Thomas Hawtin]

Andrew Thompson is a troll and is best ignored.

define:troll

"From the fishing term. As a noun, synonymous with flamebait. As a
verb, to post controversial or provocative messages in a deliberate
attempt to provoke flames."

"a newsgroup post that is deliberately incorrect, intended to
provoke readers; or a person who makes such a post"

Deliberate attempt to provoke flames? I don't think so. Deliberately
incorrect? Nope. In fact he seems to be attempting the exact opposite:
to get the newsgroup to run smoothly.

Tom Hawtin

BTW: Does no one have an answer to my applet question from two weeks ago? ;(

 

[Andrew Thompson]

Fair enough, thanks for the heads-up,

<http://groups.google.com/group/comp...a2afa86c68/7c0e78a4b4547d45?#7c0e78a4b4547d45>
A quick Google suggests Jacob is a dissatisfied
poster with a loooong grudge.

...but you couldn't take a few minutes to
take a stab at my original question could you?

(chuckle)

Andrew T.

 

[Chris Uppal]

Andrew Thompson is a troll and is best ignored.

This is untrue.

In fact I'd say that Richard's speculation is pretty near the mark.

-- chris

 

[Chris Uppal]

That is, "How can I best manage a tcp/ip socket network connection so that
it can persist during page changes".

I very much doubt whether there is any way to make such an architecture
reliable and portable across browsers.

Some problems:

What is a "browser instance" ? Some browsers run all open windows (no matter
whether invoked independently) in the same OS process. Some go further and
never exit that process, even if all browser windows are closed. Others exit
when the last window is closed.

If the user opens a window on a webpage with an applet, the browser may run
that applet in its own personal classloader. Or there again, it may not. Or
maybe it'll do so under some circumstances, but not under others.

Security considerations make it unpredictable whether, or how, the browser will
allow invisible components.

The difficulty isn't so much that there are problems like the above; but that
different browsers, with different configurations, on different OSs will solve
(or fail to solve) them in different ways.

Neither HTML nor applets are designed for this kind of architecture. I'm no
expert, but I think the best thing would be to ensure that the user stays on
the /same/ page throughout. Possibly you could use frames and/or AJAX to
implement the changing part of the interface, while the user didn't directly
navigate from page to page (yes, I know you said you didn't want to be told
about AJAX -- tough ;-)

-- chris

 

[Richard Maher]

Hi Chris,

I very much doubt whether there is any way to make such an architecture
reliable and portable across browsers.

Thanks for the replies.

Ok, regardless of how surprising I may personally find all this, the
consensus is that my strategy just won't work, and if it did happen to work
then that success could not be transfered to a multi-platform, multi-browser
scenario. I'm off back to the drawing board, but before I go please let me
amplify, and seek confirmation of, what I believe you to have (all) said
about Applet invocation and context across page changes: -

1) The whole idea of the Start() and Stop() methods for an Applet is a
complete fairytale and has never worked reliably
2) You simply cannot create a thread in an Applet and keep it running after
a page change (I know I asked about sockets but I think you can see the
analogy and what I'm getting at? That is, if you can keep a thread running
then why can't it own a Socket?)
3) You get Init() and Destroy() methods, and the latter is called whenever
the page is changed; that's it! Are we all agreed on this part at least?

So, in my case, the user will have to re-enter their Username/Password and
connect() to the application server each and every time they enter the
applet page and, for all the joy Destroy() gives me, I might as well use the
Stop() method to close() the socket and do any tidying up. "Note to User:
Don't change pages if you don't want to have to login again". Sounds
reasonable and more "secure". The Sun docs on the subject did look awfully
promising though :-(

Thanks again.

Regards Richard Maher