Java servlet, comet, long polling, websocket: I am consused !!

[sl@exabyte]

I have been reading the above topics for several days, and now utterly
confused.

I am trying to to put a server program for char room feature on my web
site. To make the server program more efficient I am thinking of using
sockets.

For the client end, I would to use socket if I can (otherwise AJAX).

At the server end, PHP or java daemon.

My questions:

1.
a) For the front end, can I use java servlet ? I understand that websocket
is not generally supported.
b) Is java servlet supported by browsers generally ?

2.
I discover that there are comet, long polling, websocket. I am very confused
now.

Can some experts discuss somewhat of all these options ?

Thanks.

 

[markspace]

a) For the front end, can I use java servlet ?

No. Servlets are server side technology.

b) Is java servlet supported by browsers generally ?

Never. Servlets are a server side technology.

However, look at Java applets:
<http://docs.oracle.com/javase/tutorial/deployment/applet/>

All GUI browsers on Mac, Linux and Windows that I know of support Java
applets. Android doesn't: use an app. iOS doesn't: use their ecosystem.

 

[sl@exabyte]

No. Servlets are server side technology.


Never. Servlets are a server side technology.

However, look at Java applets:
<http://docs.oracle.com/javase/tutorial/deployment/applet/>

All GUI browsers on Mac, Linux and Windows that I know of support Java
applets. Android doesn't: use an app. iOS doesn't: use their
ecosystem.

My apology, 'java servlet' should be 'java applet'.

I think coding in java applet allows access to sockets.

Thanks.

 

[markspace]

On 11/10/2012 8:21 AM, sl@exabyte wrote:java applet'.

I think coding in java applet allows access to sockets.

Yes it does.

<http://docs.oracle.com/javase/tutorial/networking/sockets/index.html>

<http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html>

<http://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html>

 

[Kevin McMurtrie]

I have been reading the above topics for several days, and now utterly
confused.

I am trying to to put a server program for char room feature on my web
site. To make the server program more efficient I am thinking of using
sockets.

For the client end, I would to use socket if I can (otherwise AJAX).

At the server end, PHP or java daemon.

My questions:

1.
a) For the front end, can I use java servlet ? I understand that websocket
is not generally supported.
b) Is java servlet supported by browsers generally ?

2.
I discover that there are comet, long polling, websocket. I am very confused
now.

Can some experts discuss somewhat of all these options ?

Thanks.

I'm using WebSockets with Jetty. It generally works well for two-way
text messaging and it doesn't interfere with REST/Servlet APIs. Recent
but important features, like ping/pong and different message types,
aren't supported by browsers. There's also zero error handling defined
so you'll need to work that in.

Tomcat has experimental support for WebSockets but I recommend Jetty
instead.

 

[sl@exabyte]

I'm using WebSockets with Jetty. It generally works well for two-way
text messaging and it doesn't interfere with REST/Servlet APIs.
Recent but important features, like ping/pong and different message
types, aren't supported by browsers. There's also zero error
handling defined so you'll need to work that in.

Tomcat has experimental support for WebSockets but I recommend Jetty
instead.

Just curious, have you thought about using javacript with java applet ?

If yes, what made you choose WebSockets with jetty ?

Thanks.

 

[sl@exabyte]

I'm using WebSockets with Jetty. It generally works well for two-way
text messaging and it doesn't interfere with REST/Servlet APIs.
Recent but important features, like ping/pong and different message
types, aren't supported by browsers. There's also zero error
handling defined so you'll need to work that in.

Tomcat has experimental support for WebSockets but I recommend Jetty
instead.

Just thinking. If javascript can communicate with java applet (which can
access sockets), why bother to have websocket ?

Forgive me if this is a stupid question.

 

[William Bonawentura]

I think coding in java applet allows access to sockets.

Except clients behind http proxy.

 

[sl@exabyte]

Except clients behind http proxy.

Thanks for your info. I have heard of proxy server, but not bothered with it
so far.

I did some 'google'ing on proxy server. My current understanding is the
proxy server may block the communication port. So to enable the
administrator needs to give permission to use this port.

Would MSN have the same problem ? Thanks for your guide.

 

[Kevin McMurtrie]

Just curious, have you thought about using javacript with java applet ?

If yes, what made you choose WebSockets with jetty ?

Thanks.

Applets are uncommon and so are developers for them. Sun screwed up the
Applet and GUI APIs over and over again right when Applets were needed.
HTML5 features create interactive GUIs far more easily and efficiently
than anything from Sun or Oracle.

WebSockets were chosen because they were a very simple way to provide
realtime two-way communications between client and server.

Jetty was chosen because it appears that it receives aggressive
refactoring to keep the code lean and clean. WebSocket support is
mature and cleanly integrated. Jetty also has clear layering that makes
it possible for unit tests to build a mini environment for invoking
Servlets. The downside is that configuration documentation is
incomplete.

 

[Kevin McMurtrie]

Jetty doesn't even have a clean start/stop CLI interface like
Tomcat has had all along. Tomcat is the basis for all major
Enterprise Java web servers.

Why the totally off-topic reply about the start/stop procedure?

/opt/jetty/bin/jetty.sh stop
/opt/jetty/bin/jetty.sh start

Or use the init.d scripts. That looks a lot like Tomcat.

I recommend using the server best supports the features you need.
Software developers aren't paid lots of money to make decisions based on
FUD. There's good reason for Restlet, Jetty, Resin, Tomcat, and other
engines existing.

 

[Silvio]

Jetty doesn't even have a clean start/stop CLI interface like
Tomcat has had all along. Tomcat is the basis for all major
Enterprise Java web servers.

That is utter nonsense.

 

[Arved Sandstrom]

On Wed, 28 Nov 2012 21:02:59 -0800, Kevin McMurtrie wrote:
[ SNIP ]

I recommend using the server best supports the features you need.
Software developers aren't paid lots of money to make decisions based on
FUD. There's good reason for Restlet, Jetty, Resin, Tomcat, and other
engines existing.

FUD? Nope. Mistake yes, FUD no, not at all. When WebSphere or
WebLogic decide to switch to Jetty I'll look at it again.

I'm with Kevin on this one. And bear in mind, when you say "WebSphere"
or "WebLogic" it's not like you've got this dedicated team of web
container experts, with each app server development staff, that
constantly evaluates servlet containers and gets their decisions quickly
acted upon.

In practice the resources allocated for software development on a major
JEE app server are less than you might think. Most are probably either
fixing bugs or designing/implementing new features (which latter is
driven by the marketers). If an included/embedded web/servlet container
is cutting it, and that original choice probably came down to one or a
small handful of people way back when (so why do they know more than
you, exactly?), and the cost of *change* is probably not justifiable for
incremental improvements achieved by using another container, why do you
think that what a major app server uses gives you any major guidance at all?

Other than that what they use is good for them. It's possibly not the
_best_ for them at any given time. It's very possibly not the best
choice for anyone else's requirements, although you can expect it to be
adequate.

AHS

 

[Roedy Green]

Servlets run on the Server. To the browser client they just look like
static web pages. You can run some intelligence such as Ajax, Applets
or JWS at the client. Then you can send any message format you want
back and forth.

see http://mindprod.com/jgloss/servletwomb.html

For very high speed communication, you use UDP packets. The catch is,
there is no guaranteed delivery. But often that may not matter if all
you are doing is apprising each other of current state.

See http://mindprod.com/jgloss/udp.html

 

[Arne Vajhøj]

Jetty doesn't even have a clean start/stop CLI interface like
Tomcat has had all along.

No.

Jetty comes with CLI script to start/stop.

Tomcat is the basis for all major
Enterprise Java web servers.

No.

WebSphere and WebLogic come with own.

JBoss uses Tomcat and Glassfish uses a modified Tomcat.

Arne

 

[Arne Vajhøj]

Thanks, guess I didn't look far enough.

Given that it is in the same location as for Tomcat, then
it appears that you have not been looking at all.

Tomcat is still the basis of
every major enterprise Java platform.

Still not.

FUD? Nope. Mistake yes, FUD no, not at all. When WebSphere or
WebLogic decide to switch to Jetty I'll look at it again.

They probably prefer their own.

But heard of a small company called Google?

They use Jetty!

Arne

 

[Arne Vajhøj]

My apology, 'java servlet' should be 'java applet'.

That is a bloody big difference.

I think coding in java applet allows access to sockets.

It does.

Server side is more tricky.

Either a standalone server/daemon program or a full
Java EE application-server with a JCA inbound adapter.

And you need to get through all the firewalls, which may
be easy or may be impossible.

Arne

 

[Arne Vajhøj]

Just thinking. If javascript can communicate with java applet (which can
access sockets), why bother to have websocket ?

Forgive me if this is a stupid question.

Actually it is a pretty good question.

Java applets are out of fashion - JavaScript is in fashion.

There are or will soon be 1 billion smartphones with browsers
without applet support.

A Java-JavaScript solution is more complex than a pure
JavaScript solution.

But that said, then I still consider the Java applet
solution to be a perfectly viable solution that must be
considered.

Arne