is using applet-servlet communication to implement realtime featurespossible?

[tony]

I'm on a stock(i.e. securities) project.
I have an applet showing the current prices of the stocks
and as required, the applet communicates with servlet and
servlet accesses database. Whenever prices changed, messages
should be sent to the applet.I use triggers to do the
database->servlet part, but how can I do the servlet->applet part?
As far as I know, servlet responses if and only if a request
comes to it. So is that possible?
Thank you!

 

[tony]

I'm on a stock(i.e. securities) project.
I have an applet showing the current prices of the stocks
and as required, the applet communicates with servlet and
servlet accesses database. Whenever prices changed, messages
should be sent to the applet.I use triggers to do the
database->servlet part, but how can I do the servlet->applet part?
As far as I know, servlet responses if and only if a request
comes to it. So is that possible?
Thank you!

Is my question so ambiguous that nobody wants to answer it?

 

[Tom Hawtin]

Is my question so ambiguous that nobody wants to answer it?

I believe the two common techniques are:
o Assuming chunked encoding, flush the response, but keep it open to
add to it later.
o Poll but, instead of returning nothing immediately if there is
nothing immediately available, pause until something is available.

Here's a URL to get you started:

http://en.wikipedia.org/wiki/Comet_(programming)

Alternatively you could use a non-HTTP connection. For instance SSL
socket on the HTTPS port.

Tom Hawtin

 

[Joshua Cranmer]

I'm on a stock(i.e. securities) project. I have an applet showing the
current prices of the stocks and as required, the applet communicates
with servlet and servlet accesses database. Whenever prices changed,
messages should be sent to the applet.I use triggers to do the
database->servlet part, but how can I do the servlet->applet part? As
far as I know, servlet responses if and only if a request comes to it.
So is that possible?
Thank you!

There are three ways to get information from A to B:
1. A opens a socket to a port on B and sends its data.
2. A communicates to B via an already-open socket.
3. B continually polls A for new information, downloading any that comes
its way.

Under the applet security model, #1 is probably impossible; #2 is (as far
as I know) impossible without really ignoring the HTTP specification,
which leaves #3 as the most viable option.

If you want to try method 2, you would have to have a server instance
running that injects data onto a mutually-agreed-upon port that would
probably not be a servlet instance. I don't know how servlets work, but a
persistent connection that allows you to send data down the pipe only
every once in a while (set Content-Length to some really large number and
send batches?) would be the method as to how its done.

 

[Richard Maher]

Hi Tom,

Alternatively you could use a non-HTTP connection. For instance SSL
socket on the HTTPS port.

Have you got an example of that somewhere?

Most of the stuff I've found on the web (<= 1.4) with non-authenticated
clients use something like: -

SSLSocketFactor sf = SSLSocketFactory.getDefault();
SSLSocket socket = sf.createSocket(host, port);

One of the problems I have is that the in the docs I see the createSocket
method takes 4 parameters and the first one is a non SSL socket to layered
on top of. Is this correct? Presumably that socket has to be in an
unconnected state, but wher can I specify the Socket options for a SSL
socket (setKeepAlive(), setTcpNoDelay() etc)

An example would be really, really useful here! Anyone?

As far as the OPs question, wouldn't broadcasting from the server to a UDP
socket in the Applet be the ideal way to go? Are Applets allowed to create
and read from UDP sockets?

Cheers Richard Maher

 

[tony]

There are three ways to get information from A to B:
1. A opens a socket to a port on B and sends its data.
2. A communicates to B via an already-open socket.
3. B continually polls A for new information, downloading any that comes
its way.

Under the applet security model, #1 is probably impossible; #2 is (as far
as I know) impossible without really ignoring the HTTP specification,
which leaves #3 as the most viable option.

If you want to try method 2, you would have to have a server instance
running that injects data onto a mutually-agreed-upon port that would
probably not be a servlet instance. I don't know how servlets work, but a
persistent connection that allows you to send data down the pipe only
every once in a while (set Content-Length to some really large number and
send batches?) would be the method as to how its done.

#3 is quite an easy way to do it, which my prof. doesn't allow us to. He
wants a push solution, which is like servlet actively informs applet
and applet is passive. Can you be more specifi about #2? Any simple
examples are encouraged!

 

[Nigel Wade]

Is my question so ambiguous that nobody wants to answer it?

One way is for an applet to make a request to a servlet which blocks waiting for
a response. So you could possibly get it to work using threads. A background
thread in the applet could make a request to the servlet, and this only returns
when there is a price change to report. When the request returns to the applet
this new data can be made available by some mechanism to other threads in the
applet. Those other threads can process the data whilst the background thread
makes another blocking request. You'd have to handle timeout on the blocked
request, as well as network outages and the like. And properly synchronize the
data shared between the threads in the applet.

You would also need to take account of what happens to price updates which occur
whilst no request is currently blocked, i.e. during the period between one
request returning with an update and the applet background thread making
another request. You wouldn't want updates during this time interval to fall
through the cracks so the servlet would need to cache updates somehow.

It won't be trivial.

I do something similar to this in a applet/servlet setup which displays realtime
data from a radar. However, if the comms. in my setup breaks no-one loses any
money...

 

[tony]

One way is for an applet to make a request to a servlet which blocks waiting for
a response. So you could possibly get it to work using threads. A background
thread in the applet could make a request to the servlet, and this only returns
when there is a price change to report. When the request returns to the applet
this new data can be made available by some mechanism to other threads in the
applet. Those other threads can process the data whilst the background thread
makes another blocking request. You'd have to handle timeout on the blocked
request, as well as network outages and the like. And properly synchronize the
data shared between the threads in the applet.

You would also need to take account of what happens to price updates which occur
whilst no request is currently blocked, i.e. during the period between one
request returning with an update and the applet background thread making
another request. You wouldn't want updates during this time interval to fall
through the cracks so the servlet would need to cache updates somehow.

It won't be trivial.

I do something similar to this in a applet/servlet setup which displays realtime
data from a radar. However, if the comms. in my setup breaks no-one loses any
money...

That's an easy solution, but not the one my Prof. wants!
A push solution is favored over a pull one.
I'm trying to implement it by Comet tech now, but I can't find good
examples so I'm no closer to solving it.

 

[Guest]

I'm on a stock(i.e. securities) project.
I have an applet showing the current prices of the stocks
and as required, the applet communicates with servlet and
servlet accesses database. Whenever prices changed, messages
should be sent to the applet.I use triggers to do the
database->servlet part, but how can I do the servlet->applet part?
As far as I know, servlet responses if and only if a request
comes to it. So is that possible?

The whole concept applet-servlet sounds a bit 1990'ish to me.



A servlet speak HTTP and servlets are expected to complete
when running, so I would say your options are:

1) let the applet poll the servlet via normal HTTP
2) let the applet connect to a standalone Java server
app using sockets
3) use a JCA adapter

Arne

 

[Richard Maher]

Hi,

1) let the applet poll the servlet via normal HTTP
2) let the applet connect to a standalone Java server
app using sockets
3) use a JCA adapter

Is there really no place for DatagramSocket.receive here? Or is it one of
the things (unsigned?) Applets can't do?

Cheers Richard Maher

 

[Antti]

I'm on a stock(i.e. securities) project.
I have an applet showing the current prices of the stocks
and as required, the applet communicates with servlet and
servlet accesses database. Whenever prices changed, messages
should be sent to the applet.I use triggers to do the
database->servlet part, but how can I do the servlet->applet part?
As far as I know, servlet responses if and only if a request
comes to it. So is that possible?
Thank you!

Have you checked www.pushlets.com? There should be some good examples
to start with. Long ago I think they even used a stock example

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Is there really no place for DatagramSocket.receive here? Or is it one of
the things (unsigned?) Applets can't do?

The problem is not the applet but the servlet.

Whether #2 and #3 uses TCP or UDP does not matter.

Arne

 

[Richard Maher]

Hi Arne,

The problem is not the applet but the servlet.

Whether #2 and #3 uses TCP or UDP does not matter.

It was the "connect" or "Connection" bit that threw me. Look, I've never
done this so it may not be this simple, but I imagine your "stand alone"
server (and only one instance of) could send multicast messages out over the
network and if the Applet has subscribed to such messages then it's
receive() (probably in a seperate thread) will update it's part of the page
with the latest price info.

There must be an example of this on the web somewhere?

Cheers Richard Maher

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Hi Arne,


It was the "connect" or "Connection" bit that threw me.

Yes - that sound a bit TCP'ish.

Look, I've never
done this so it may not be this simple, but I imagine your "stand alone"
server (and only one instance of) could send multicast messages out over the
network and if the Applet has subscribed to such messages then it's
receive() (probably in a seperate thread) will update it's part of the page
with the latest price info.

Now you bring it up. I wonder how default applet security have
it UDP.

http://www.cs.utk.edu/~lchen/software/java/udping/

and other googlable links indicates that it is possible.

And

 

[Richard Maher]

Hi Arne,

Now you bring it up. I wonder how default applet security have
it UDP.

http://www.cs.utk.edu/~lchen/software/java/udping/

and other googlable links indicates that it is possible.

Short of just trying it, I couldn't find anything on the net (including
SUN's docs) that explicitly stated whether an Applet could receive broadcast
UDP messages and, if so, from whom. (I'm guessing that as long as the
datagrams are going to/from the codebase then no applet-signing is reqd)
Which brings me to the MulticastSocket class and some O'Reily book that says
Multicast methods are a huge security risk and forbidden for
unsigned-Applets. Does anyone know when and why the
SecurityManager.checkMulticast() code would throw an exception for an Applet
that just wants to receive datagrams that have the originating source
details that can be later checked against the codebase?

Anyway, if the OP is still there this is what I'd suggest: -

1) Combo of a) Connection-oriented, context rich TCP/IP socket and b)
Multicast socket
2) Connect to the Application Server and pass authorization via a)
3) Join/subscribe to the Stockwatch multicast group via b)
4) Stand-alone server process picking triggered database changes and
broadcasting to the group
5) For each client seperate thread reading b) and outputing results
6) If a client recieves a message which has a sequence number that is older
than the last one read then ignore it
7) If there is a gap between the previous message sequence received and the
new on than use a) to re-calibrate
8) Server sends heart-beat messages every "n" seconds with next sequence
number
9) If client hasn't received a message after "n" seconds then use a) to
check

Again, I'm guessing that this is what all the "chat" software does? Or those
Wimbledon score update windows?

If you're stuck with Datagram Sockets then the server must keep track of
subscribers and it's all a bit messy.

I looked around for a MulticastSocket Applet example and couldn't find one;
maybe you'll have better luck?

Cheers Richard Maher

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Hi Arne,


Short of just trying it, I couldn't find anything on the net (including
SUN's docs) that explicitly stated whether an Applet could receive broadcast
UDP messages and, if so, from whom.

The code in the link above do receive.

(I'm guessing that as long as the
datagrams are going to/from the codebase then no applet-signing is reqd)

It seems logical.

But it should be tested.

I looked around for a MulticastSocket Applet example and couldn't find one;
maybe you'll have better luck?

I can't find any either.

Arne