Making a socket server connection from java applet

[mikek]

Does anyone have any experience with making a socket server connection
from an applet embedded in a web page? Specifically, I am able to
establish the socket server connection without any problem - that is,
after signing the applet with a certificate. However, after leaving
the page and returning, the socket connection is always unavailable
(non bindable). The only way to re-establish a connection is to close
the web browser completely and re-open it. I've tried to close the
connection in the applet "stop()" callback, but to no avail.

 

[EJP]

(non bindable).

What exactly do you mean by this?

 

[Richard Maher]

Hi Mikek,

Does anyone have any experience with making a socket server connection
from an applet embedded in a web page? Specifically, I am able to
establish the socket server connection without any problem - that is,
after signing the applet with a certificate. However, after leaving
the page and returning, the socket connection is always unavailable
(non bindable). The only way to re-establish a connection is to close
the web browser completely and re-open it. I've tried to close the
connection in the applet "stop()" callback, but to no avail.

You don't need to sign an applet if it connects back to the codebase (which
can be a million miles away from the document base)

The reliance on stop/start maybe the problem but, FWIW, you can look at the
..java files at: -

http://manson.vistech.net/t3$examples/

CornuCopiae.java is the Applet and Tier3Socket.java does most of the Socket
work.

"Java Applets and Sockets" - It's all good!

Cheers Richard Maher

PS. Just wait for the: -

- Single-Signon without session-hijackable cookie bollocks?
- Single, persistent network connection across multiple active tabs in a
browser instance?
- Full-on synchronous of asynchrous i/o capability?
- 1:M relationship between messages sent to received?
- Retention of server-affinity if/when needed?

You know you want some of that!!!

 

[mikek]

Hi Mikek,




You don't need to sign an applet if it connects back to the codebase (which
can be a million miles away from the document base)

The reliance on stop/start maybe the problem but, FWIW, you can look at the
.java files at: -

http://manson.vistech.net/t3$examples/

CornuCopiae.java is the Applet and Tier3Socket.java does most of the Socket
work.

"Java Applets and Sockets" - It's all good!

Cheers Richard Maher

PS. Just wait for the: -

- Single-Signon without session-hijackable cookie bollocks?
- Single, persistent network connection across multiple active tabs in a
browser instance?
- Full-on synchronous of asynchrous i/o capability?
- 1:M relationship between messages sent to received?
- Retention of server-affinity if/when needed?

You know you want some of that!!!

The reason for signing the applet is that, in this case, the applet is
opening a local server connection allowing other devices on the
network to connect to it (e.g. 192.168.1.102 might be the local IP
that allows a local network device to access the applet). What I meant
by non-bindable is that this is the error message in the java console
when the applet tries to open the server connection after, for
example, navigating away from the page and then returning to it. The
problem is that when navigating away from the page and then returning,
the applet thinks the connection is closed but the browser must be
keeping it open.

 

[Roedy Green]

I've tried to close the
connection in the applet "stop()" callback, but to no avail.

Perhaps you did not properly close the connection. Show us your
open/close code.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"The coolest thing to do with your data will be thought of by someone else."
~ Rufus Pollock (born: 1978 age: 31) in Talk.

 

[Knute Johnson]

What I meant
by non-bindable is that this is the error message in the java console
when the applet tries to open the server connection after, for
example, navigating away from the page and then returning to it. The
problem is that when navigating away from the page and then returning,
the applet thinks the connection is closed but the browser must be
keeping it open.

Most likely what is happening is that the socket is not getting closed
when you navigate away. I worked on a project a few months ago that
used applets to communicate with a server program running at the
applet's host. I do know that you must use the new plugin which is only
available in later versions of 1.6 (I can't remember exactly which).
The reason for this is that stop() and destroy() may not get called in
earlier versions when the browser leaves the page. Also there may be
problems with certain browser versions too.

 

[Richard Maher]

Hi,


Which browser? Could be worthwhile ruling out BACK button optimization by
sticking an "onunload" function on your web-page.

Most likely what is happening is that the socket is not getting closed
when you navigate away.

I agree.

I worked on a project a few months ago that
used applets to communicate with a server program running at the
applet's host. I do know that you must use the new plugin which is only
available in later versions of 1.6

I don't agree. (At least in a general sense without know your specific
project requirements)

The example code I pointed to quite happily closes the Socket when you
navigate away from the page and then back again. If you don't believe me
try: -

http://manson.vistech.net/t3$examples/demo_client_web.html

Username: TIER3_DEMO
Password: QUEUE

(I can't remember exactly which).
The reason for this is that stop() and destroy() may not get called in
earlier versions when the browser leaves the page. Also there may be
problems with certain browser versions too.

Cheers Richard Maher

 

[Knute Johnson]

I don't agree. (At least in a general sense without know your specific
project requirements)

The example code I pointed to quite happily closes the Socket when you
navigate away from the page and then back again. If you don't believe me
try: -

Richard, I just curious, what part don't you agree with? The part about
using the new plugin or that it is only available with the newer 1.6?

Thanks,

 

[Richard Maher]

Hi Knute,

Richard, I just curious, what part don't you agree with? The part about
using the new plugin or that it is only available with the newer 1.6?

The part where you say "I do know that you *must* use the new plugin". The
Tier3.jar file that the example uses was built with 1.4.2_13 and has no
trouble at all without the new plugin. (And also performs very well with the
new plugin) If you were refering to better or more predictable support for
stop/start methods with the new plugin then I'm happy to hear about it, but
for the OP's case I think it could be beneficial to change to init/destroy
if moving off/on a page is what he's looking at.

Thanks,

Cheers Richard Maher

 

[jolz]

Did you set SO_REUSEADDR ?

 

[Knute Johnson]

Hi Knute,



The part where you say "I do know that you *must* use the new plugin". The
Tier3.jar file that the example uses was built with 1.4.2_13 and has no
trouble at all without the new plugin. (And also performs very well with the
new plugin) If you were refering to better or more predictable support for
stop/start methods with the new plugin then I'm happy to hear about it, but
for the OP's case I think it could be beneficial to change to init/destroy
if moving off/on a page is what he's looking at.

Cheers Richard Maher

Prior to the new plugin any running threads could just be destroyed
without finishing including the one running stop() and destroy(). This
makes cleanup very difficult and is most likely (in my opinion) the
cause of the OPs problem.

 

[EJP]

What I meant
by non-bindable is that this is the error message in the java console
when the applet tries to open the server connection after, for
example, navigating away from the page and then returning to it.

So why does the applet try to open the 'server connection' *again?*

If the applet has been unloaded and has destroyed itself correctly it
should have closed the ServerSocket so it should be able to open a new
on when it is initialized.

If it hasn't been destroyed it should still have a reference to the
existing ServerSocket.

BTW this is not a 'connection', it is a ServerSocket, which is a passive
listening endpoint.