Re: is using applet-servlet communication to implement realtime features possible?
- From: "Richard Maher" <maher_rj@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Jul 2007 20:48:48 +0800
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
"Arne Vajhøj" <arne@xxxxxxxxxx> wrote in message
news:46902295$0$90262$14726298@xxxxxxxxxxxxxxxxxx
Richard Maher wrote:the
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.
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
pagenetwork 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
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
.
- Follow-Ups:
- References:
- Re: is using applet-servlet communication to implement realtime features possible?
- From: Arne Vajhøj
- Re: is using applet-servlet communication to implement realtime features possible?
- From: Richard Maher
- Re: is using applet-servlet communication to implement realtime features possible?
- From: Arne Vajhøj
- Re: is using applet-servlet communication to implement realtime features possible?
- From: Richard Maher
- Re: is using applet-servlet communication to implement realtime features possible?
- From: Arne Vajhøj
- Re: is using applet-servlet communication to implement realtime features possible?
- Prev by Date: Re: Backing Up Objects
- Next by Date: Re: Reflection on Jar NOT in Classpath?
- Previous by thread: Re: is using applet-servlet communication to implement realtime features possible?
- Next by thread: Re: is using applet-servlet communication to implement realtime features possible?
- Index(es):
Relevant Pages
|