TCP ports for outbound connections.

[Vedran Bartonicek]

I am wandering how is Tomcat deciding which own tcp ports to use when sending a http request? Is that is randomly select? Is it possible to specify the port range in some of the config files?
Thanks, Vedran

[Tim Holloway]

Welcome to the JavaRanch, Vedran!

Tomcat doesn't send HTTP Requests. It only listens for and receives them. It then routes the incoming requests to their associated webapps, which provide the application functionality, including the generation of the HTTP Response, which is then sent back to the client. Every request has one and only one response and Tomcat never initiates activity on its own, only responds to client requests. That's how the HTTP standard (RFC) defines the Web.

If what you're looking for is to control the port used as a response (reply) port, Tomcat does not handle that. The OS's tcp/ip stack manages that. So you'd have to adjust the OS network configuration.

[Tim Moores]

That's controlled by the OS, not Tomcat. I'm fairly certain that Tomcat can't influence that.

[Vedran Bartonicek]

Tim Holloway wrote:
Tomcat doesn't send HTTP Requests. It only listens for and receives them.

.

I was thinking about the case when a servlet running on a tomcat would create a http request to another server. So I was assuming that tomcat, as a JavaEE container, has control over tcp port selection in that case.
But there is already a suggestion that OS controls this.

P.S. Thumbs up for the warm welcome!

[Tim Holloway]

For the case of a servlet making an HTTP request to another server, the servlet has total control over that. Tomcat doesn't get involved at all. To select a port, just code it in the URL that the servlet addresses in the usual way: protocol://server:port/context/etc like so: http://www.fakeserver.com:9080/webapp2/stuff

[Tim Moores]

Vedran Bartonicek wrote:I was thinking about the case when a servlet running on a tomcat would create a http request to another server.

Oh, you're asking about the port on the remote server? Yes, your code has full control over that. When you said "outbound" I assumed you were talking about the local port being used.

[Vedran Bartonicek]

Tim Moores wrote:

Vedran Bartonicek wrote:I was thinking about the case when a servlet running on a tomcat would create a http request to another server.

Oh, you're asking about the port on the remote server? Yes, your code has full control over that. When you said "outbound" I assumed you were talking about the local port being used.

You are right, I did asked about the local port on tomcat, not remote port.

[Vedran Bartonicek]

Tim Holloway wrote:For the case of a servlet making an HTTP request to another server, the servlet has total control over that. Tomcat doesn't get involved at all. To select a port, just code it in the URL that the servlet addresses in the usual way: protocol://server:port/context/etc like so: http://www.fakeserver.com:9080/webapp2/stuff

I think that my question was misunderstood :-)
I was asking about local port on Tomcat, not remote port. Is Tomcat, and where, defining it in case of outbound tcp connection (e.g. servlet on tomcat making a http request to another web server).
Cheers!

[Tim Holloway]

Tomcat doesn't have an "outbound port". When you make a TCP/IP connection, you connect to a remote port, and you listen for the response on a reply port. Data goes to ports, not from them.

Which brings us back to what I'd said earlier. The selection of a reply port is defined by the OS, not the network application (Tomcat). The network's TCP/IP stack maintains a pool of reply ports and assigns from there.

[Tim Moores]

Tim Holloway wrote:Data goes to ports, not from them.

Gotta disagree with that, there's also a local port involved that is not under the control of the client software. That's what the Servlet API calls the "remote" port (since it's got the view from the server-side perspective).

[Vedran Bartonicek]

Tim Holloway wrote: Data goes to ports, not from them..

Hm...I would disagree with the quoted statement, TCP is a full duplex protocol. Data can go both ways, listening port on sending side( at tcp stack below tomcat) is sent with SYNC msg at the TCP handshake.
So sending side defines the listening port.
Do correct me if I am wrong.
But, thanks, my original question was probably answered ;-)

[Tim Holloway]

Tim Moores wrote:

Tim Holloway wrote:Data goes to ports, not from them.

Gotta disagree with that, there's also a local port involved that is not under the control of the client software. That's what the Servlet API calls the "remote" port (since it's got the view from the server-side perspective).

I think you'll find that that's the client's Reply Port a/k/a "ephemeral port", and yes, it's inbound to the client, not outbound from Tomcat. The Tomcat server doesn't control that. When the client makes a tcp request to Tomcat, the client machine's tcp stack obtains an ephemeral port ID from the reply port pool, puts the port number in the first 2 bytes of the tcp packet (the second 2 bytes are Tomcat's server port number), does all the other related stuff, sends out the packet and sets up a client-side listener on the Remote (Reply) Port for the Tomcat response to come back to.

Every TCP packet contains a source and destination port ID. One of each, no more, no less. If the packet goes through a proxy, the ports may be altered and the original ports passed as headers in the larger data stream, but the actual TCP transmission header reflects the source and destination of the packet itself.