I was asked the following question in an interview.
"Supposing a servlet recieves two requests from different clients at the same time. Client A needs to search the new movies in town. Client B needs to search a magazine section. The servlet provides both these services. It generates the required responses. Now, how does it know whom to send which response?"
I responded with all that i knew about session management and the connector(COYOTE), container(CATALINA) architecture of APACHE TOMCAT. The interviewer said I was close, but not correct.
I've tried googling, and re-read the first few chapters of J.Hunter's book. Did not find any great explanations.
Is it the job of the servlet to identify the clients of individual requests to send the response back?
I've done some servlet coding(tech. demonstration purposes & school requirements), but not in a production environment.(Just Outta School!)
Do people in the industry code their servlets to respond to their clients based on their IP addresses? If so, why aren't these procedures mentioned in the textbooks?
Any explanation will be greatly appreciated. [ August 21, 2004: Message edited by: chowdary Thammineedi ]
Joined: Aug 12, 2002
Hi, The doPost or doGet method always recieves request and response together. And response will always be sent to where request originated from.
Joined: Aug 02, 2004
OK, let's up the ante a little. You have two browsers on the same machine that each submit different requests to the same servlet. The servlet receives the request details in the HTTP message header. For both requests a sniffer might show the output as follows:
The response from one servlet contains the following (for example):
HTTP Status Code: HTTP/1.0 200 OK Date: Fri, 20 Aug 2004 15:07:43 GMT Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector) Content-Type: text/html;charset=ISO-8859-1 Pragma: no-cache Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Expires: Wed, 31 Dec 1969 23:59:59 GMT Set-Cookie: JSESSIONID=A8869016768081C245F3907770E01299;Path=/ X-Cache: MISS from www.my-server.co.uk Connection: close CRLF
The second servlet response differs only in the JSESSIONID cookie.
So, when the two responses come back, how does browser A know that it's response is response A and not browser B's response B? Well, I believe that the answer is that this is not part of the HTTP protocol; it's handled in the layers below by TCP. Each browser will be listening on a different TCP port for the response to their request and that's how they know the difference. At the server-side the response is directed to the appropriate TCP port, but it's not part of the HTTP protocol.
So, what's the point of the JSESSIONID cookie then? The next time a request is submitted to the same servlet the cookie is sent with the request headers and the JSESSIONID identifies it as being part of the same session as previous requests.
So, in conclusion, the session ID has nothing to do with how responses are routed from the server to the browser, although it is passed back with the response. It comes into its own in tying together a sequence of requests.
I think everything I've said is pretty much accurate, but if I'm not 100% on the mark then please correct me.
Hope this is useful and interesting.
Joined: Aug 16, 2004
I was thinking along the same lines too.
The servlet container recieves the (request,response) bundle from the connector, processes the request, generates the response, bundles them together again and sends it back to the connector. The connector then has to examine it, identify the request, lookup the corresponding client and send the response back.
Am i Thinking Right? May be I need to get my TCP funda in order!