Well basically, For the output servlet, I am using comet to keep the connection alive and push things out to the client when they are available. This program is a chat program with a drawing capability, so two people can draw on the same canvas and chat with each other.
On Fri, Jul 13, 2012 at 10:02 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Elias, > > On 7/13/12 9:39 AM, Elias Kopsiaftis wrote: > > I am working on a program that uses two servlets, one for input > > from the client, and one for output to the client. > > Good so far. > > > My question is, from the client side, I will have two connections > > open to the server, one for input, and one for output > > Okay, you've lost me: what you've described is not how HTTP works. A > client makes one (or more) connection(s), sends a request (on each > connection) and receives a response over the same connection. > > > so, when both connect, will both connections have the same > > sessionid even though they are accessing two different servlets? > > both servlets will be on the same tomcat > > Well, if you are using cookies and your client manages them globally, > then all connections should be associated with the same session. This > is the case with most web browsers in their default configuration. > > If you are using URL re-writing to maintain session affinity, then > you'll have to make sure that all of the URLs that you issue from the > client to the server have the URL properly encoded. If you have > written your webapp correctly, most of this should be taken care of by > the container. Your client also has to be willing to include "path > parameters" in the URLs that it passes-back to the server. This is > also the case with most web browsers in their default configuration. > > But back to your plan to make separate "input" (to the server) and > "output" (from the server) connections does not make any sense unless > you have some justification for making things that complicated. > > I'm available for enlightenment, though I suspect your requirements > are actually a lot simpler than what you describe. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAA00MACgkQ9CaO5/Lv0PDz5ACePY07/LBELtlspcvC2U+k0hoF > oSgAnieuXC7721SMfwUzD0gWfZHaFwaB > =T9FG > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >