 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007is using applet-servlet communication to implement realtime features possible?
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! > I'm on a stock(i.e. securities) project. > I have an applet showing the current prices of the stocks [quoted text clipped - 5 lines] > comes to it. So is that possible? > Thank you! Is my question so ambiguous that nobody wants to answer it? >> I have an applet showing the current prices of the stocks >> and as required, the applet communicates with servlet and [quoted text clipped - 5 lines] > > 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 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 > >> I have an applet showing the current prices of the stocks > >> and as required, the applet communicates with servlet and [quoted text clipped - 20 lines] > > Tom Hawtin >> I'm on a stock(i.e. securities) project. >> I have an applet showing the current prices of the stocks [quoted text clipped - 7 lines] > > 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...  SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 >>> I'm on a stock(i.e. securities) project. >>> I have an applet showing the current prices of the stocks [quoted text clipped - 28 lines] > 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. > 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 [quoted text clipped - 4 lines] > 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. >> 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 [quoted text clipped - 21 lines] > 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! > I'm on a stock(i.e. securities) project. > I have an applet showing the current prices of the stocks [quoted text clipped - 4 lines] > 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 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 > > I'm on a stock(i.e. securities) project. > > I have an applet showing the current prices of the stocks [quoted text clipped - 18 lines] > > Arne >> 1) let the applet poll the servlet via normal HTTP >> 2) let the applet connect to a standalone Java server [quoted text clipped - 3 lines] > 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 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 > >> 1) let the applet poll the servlet via normal HTTP > >> 2) let the applet connect to a standalone Java server [quoted text clipped - 9 lines] > > Arne > Hi Arne, > [quoted text clipped - 3 lines] > > 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 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 > > Hi Arne, > > [quoted text clipped - 21 lines] > > And > Hi Arne, > [quoted text clipped - 8 lines] > 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 > I'm on a stock(i.e. securities) project. > I have an applet showing the current prices of the stocks [quoted text clipped - 5 lines] > 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 ;) -- Antti Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.