OK, since I am trying to have java-based applications end-to-end and since I own this network, I think I will use TC and Java Web Start instead of applets ~ >> This would be beneficial if you want to use an internal, local >> network cache for a number of users you know in a network you own >> ~ >> Which each user's login a connection is open transparently to that >> user in a tomcat server that just works as a cache. Different users >> are not supposed to trample on each others' connections
> What's wrong with a standard HTTP-based web application with requests > and responses? ~ I know the maximal number of clients that can be in this network and TC can keep, say, 50 connections open, so I thought I would set up these connections once users login or switch the box on, so that they have access to their files through the JWS app from any of the boxes they could use in the lab ~ Thanks lbrtchx On Fri, Aug 8, 2008 at 11:19 AM, Christopher Schultz <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Albretch, > > Albretch Mueller wrote: > | 1) Can you achieve such a thing as a registered, dedicated, always > | open connection to each client in a network from login to logout using > | tomcat? > > Not really. HTTP is designed as a connectionless protocol. You might be > able to do this using the Comet Connector (about which I am completely > ignorant). > > These days, everyone uses AJAX to make web applications appear to have > constantly-updating screens and things like that. > > | 1.1) How can browsers be configured to take advantage of them? > > Server-push is an option, but is sucks. AJAX is your best bet IMO. Or, > use an entirely different protocol instead of HTTP (you could do this > using a Flash-based app or a Java applet). > > | 1.2) What would you suggest if I would like this configuration to be > | available to different browsers, the user may have? > > Flash is much more available than Java for web browsers. > > | This would be beneficial if you want to use an internal, local > | network cache for a number of users you know in a network you own > | ~ > | Which each user's login a connection is open transparently to that > | user in a tomcat server that just works as a cache. Different users > | are not supposed to trample on each others' connections > > What's wrong with a standard HTTP-based web application with requests > and responses? > > | 2) In the (2004) article "Concerning Etags and Datestamps" > | > | [snip] > | > | The part I wouldn't totally agree with or that is not clear to me is > | "The first method involves an extra connection for each download, > | which takes time and server resources." > | > | I think when you hit a server with a "HEAD" request, the server just > | returns the meta-data without trying to setup sessions > > Not necessarily. The server can do anything it wants to do. A HEAD > request is handled separately from the (possible) following GET request, > so if there are headers to be parsed and resources to check (such as the > size of a file, etc.), all that work will have to be done for the HEAD > request before anything can be sent back. That same work is likely to be > repeated when the GET request comes a moment later. > > | or "keep-alive" > | connections from that client in an unencumbered way, but if you "GET" > | connections to server resources, servers will do the setup to estabish > | ongoing connections to that client, so then when you drop the > | connection after reading the headers, servers do keep the connection > | open wondering that went of with the client . . . > > No, the server should see a dropped connection and just close and > cleanup the connection on the server side. It's true that a lot of work > might be needlessly done on the server side if the client just plans to > hand up the connection. > > | So, I think it you know that the server most likely didn't change > | some data and that the particular server reliably reports HTTP > | headers, then it is better to conditionally go with "HEAD" first > | > | Is it true? Am I missing something? > > I agree with the author that using If-Modified-Since and similar > strategies are the best bet because you are basically doing a HEAD + GET > with a single request. There are special response codes for the server > to use when the response should be "content has not been modified" > versus "content has been modified, and here it is". > > Feel free to use HEAD followed by GET, but GET with predicates is > certainly going to be faster if the server correctly supports the > predicates themselves. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkicZA0ACgkQ9CaO5/Lv0PBfvQCgh7CIJNXXy8echulIxOXqbsSL > i40AoJ7UxsEslVo+lFoBERtyVA8UcO3U > =IW8M > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
