getLocalPort()

[Anand Wadhwani]

Could anyone please explain what does the getLocalPort() method of request returns? Is it a software port? The getRemotePort and getServerPort are the hardware port? If total number of software ports are limited to say 65536, this means no more than 65536 threads can be created, which means no more than 65536 client requests can be served from this server? Pls explain.

Thanks Much!

[Nathaniel Stoddard]

Yes, the localPort is a logical "software" port. In case you don't realize how things happen: when a user asks for a file from port 80 (typical HTTP port), the request goes to 80. The server, which is listening on 80 notices that someone's asking for something, so it chooses another random port, e.g. 1083, and creates a separate thread to actually service the request.

In this case, localPort would be 1083, serverPort would be 80. And the amount of ports available to service requests would be dependent on the operating system. I'm not sure how many is correct or what it really depends on. What I do know is that if you're servicing 65536 clients simultaneously, you'll want to get that sucker load-balanced on a few other boxes.

[Pradeep bhatt]

Nathaniel ,

Since the client only knows about port 80 how will it communicate with port 1083 ? Is there a redirection involved ?

[Charles Lyons]

If total number of software ports are limited to say 65536, this means no more than 65536 threads can be created, which means no more than 65536 client requests can be served from this server?

No. Each port can receive a number of simultaneous TCP connections up to the number configured in the server. The default in my Apache configuration is 150. Connections are typically made to port 80 or, for a single J2EE Web container, port 8080. Note that a browser always defaults to port 80 for HTTP requests, if no other port is specified after the host in the URL.

In case you don't realize how things happen: when a user asks for a file from port 80 (typical HTTP port), the request goes to 80. The server, which is listening on 80 notices that someone's asking for something, so it chooses another random port, e.g. 1083, and creates a separate thread to actually service the request.

I don't agree that the server sends the request to some other random port - that would cause chaos. When a request is made to port 80, the request stays at port 80, and the server can connect up to its pre-configured maximum number of clients (mine is 150). If you decrease this figure, less clients can connect. If you increase it, you risk the server running out of resources. Any clients that cannot connect due to a busy server will receive an HTTP 500(.13) status code and will be rejected (they'll have to try again later).

If you try to access any other port on the machine, you normally won't get very far. If you want to look into sockets further, try the java.net package and the socket classes.

Plus, I've got (non-Web) services running on other ports, so if the server did "randomly" choose a port, that could interfere with other services. Recall also that a service must be configured on a port before it could be used. If you want to configure a Web server to run on all ports from 1024 to 65536 you're welcome, but personally I wouldn't waste the resources.

In this case, localPort would be 1083, serverPort would be 80. And the amount of ports available to service requests would be dependent on the operating system. I'm not sure how many is correct or what it really depends on.

It's not the number of ports available, its the number of connections which can be made on a single port. As I say, my maximum simultaneous TCPs is 150 on port 80.

To answer the original question about redirection, my Tomcat instance runs on a different port (can't remember exactly what it is, but say it's 8056). The server uses the mod_jk Apache plug-in to redirect requests matching certain URIs from port 80 (the default HTTP port) to port 8056 where Tomcat is running. Tomcat then uses it's own filter to determine which Web application I want the request to be received by.

Plus, if you've got multiple containers running (as a hosting company does), you start each container on a different port and redirect requests from port 80 to the appropriate Tomcat port, using mod_jk and its workers.properties configuration file.

But there is a limitation in the mod_jk connector. If I try the following JSP:

<%= request.getLocalPort() %><br />
<%= request.getLocalName() %><br />
<%= request.getServerPort() %><br />

I find I actually get the results:

80
mydomain.com
80

What's happening is the mod_jk connector is passing Tomcat the localPort of 80 as the port on which connections were received. This isn't incorrect: the Servlet API states that getLocalPort() "returns the Internet Protocol (IP) port number of the interface on which the request was received." Of course, the request was originally received (by Apache) on port 80, so this is the return value I get.

If I want to get the port the request was received on by Tomcat, a configuration option (UseCanonicalName, I think) in mod_jk forces the plug-in to pass the new (redirected) port to Tomcat as the localport. Hence, with this option set, getLocalPort() would in fact return 8056 rather than 80.

This distinction is largely irrelevant; checking port numbers is generally rarely useful, and as you can see, it's a Web server-implementation dependent minefield!

For more information on Tomcat configuration (with Apache or IIS) see the Connector docs:

http://tomcat.apache.org/connectors-doc/howto/index.html
[ July 13, 2006: Message edited by: Charles Lyons ]

[Pradeep bhatt]

Thanks Charles Lyons.

It's not the number of ports available, its the number of connections which can be made on a single port. As I say, my maximum simultaneous TCPs is 150 on port 80.

In such a case how does a server handle a larger number of simultanrous requests say 10,000.


The ServerSocket constructor takes a backlog parameter. For the above example backlog =150 , right ?

[Charles Lyons]

In such a case how does a server handle a larger number of simultanrous requests say 10,000.

When a page is requested and the response returned, the actual TCP connection to the server is very short - say a few milliseconds in duration. Remember that the page is only downloaded once for viewing, so even if the client has the resource open for the user to see for minutes, hours or even days, the request and TCP connection would have closed a long time ago. So there's a window of a good few milliseconds during which each connection is alive, and unless all 10,000 clients simultaneously create TCP connections during those few milliseconds, there will be no problem. In addition, if the number of simultaneous connections does exceed the maximum (e.g. 150), the browser will probably try again a few more times before giving up.

Say the TCP connection is made for 10ms per request (that's quite large; most of the delay in TCP connections is caused by relatively slow speeds in the network hardware) and our connection queue size is limited to 150, then that gives us approximately 1500 clients per second. Now how many are going to be connecting in the same second? If it's less than 1500 we're okay... that means they'll be about 15,000 in 10 seconds, which is the region of figure you're looking for.

Of course, a larger network (with more powerful machines) can set the queue size to more than 150. Much larger networks use clusters of servers to perform load-balancing. If you're really getting anywhere near 10,000 simultaneous users, you might want to consider a cluster (although that gets expensive!).

The ServerSocket constructor takes a backlog parameter. For the above example backlog =150 , right ?

Since Tomcat is Java-based, yes, the 150 would be the backlog (I prefer to call it "queue") argument for the ServerSocket listening on your Tomcat port. For the Apache Web server example I quoted, Apache isn't Java-based, so it wouldn't use a ServerSocket (instead it would use a non-Java equivalent).

[Pradeep bhatt]

Thanks. Very good explanation.