"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Sep 2001, Joe Pearse wrote:
>
>> Date: Fri, 07 Sep 2001 16:49:09 -0700
>> From: Joe Pearse <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Subject: Re: Specify outbound port on tomcat
>>
>> The application itself is generating the message being sent out. In the
>> basic sense, a browser is not involved. For example, information is
>> received on port 443, and processed by the application. From that, a
>> java.net.URL object is created, and the message is fired off to the
>> specified client URL. When firing off the message, the outbound port
>> (1024-5000) is chosen, and I'm not sure what chooses the port, and if I can
>> restrict it.
>
> OK, to make an outbound connection, you definitely need a port on the
> local server. But what matters to a firewall is the port on the
> *destination* of that connection, not the *origin*. What port number on
> the client are you sending to? In order for things to work, *this* is the
> port number your firewall has to allow through (assuming that the client
> is on the other side of it, of course).
Well... Not really... My firewall, for example, is configured to deny access
to the outside world if the originating port is < 1024...
A connected socket is always represented as a 96 bits value (header in the
TCP packet), and that include
Source IP (32b) - Source Port (16b) - Target IP (32b) - Target port (16b)
Most firewalls are actually configurable to filter out also outbound
connections. This is because under UNIX, root initiated connections use port
< 1024, and you don't want to allow a root process on the machine to be able
to forward data to the outside world...
> Which, of course, raises the question of why do this anyway, when you can
> simply return data in the HTTP response to the request you are processing,
> but that's a different question.
When working with my previous employer, we were doing EbXML over HTTP, using
Tomcat, and what usually happened was that at request time the only response
sent back to the client was "I received your request, and it's sintattically
correct". Then the request was appended to the job queue and processed.
Responses were sent maybe HOURS later the request arrived, depending on how
long the process took to finish.
For example, a customer might ask me thru HTTP a quote for a product. And in
that case, I want a real person to do some calculation, and decide what kind
of discount I can give to that customer. Once this has been processed, and
"manually" entered in my BPMS job queue, then my server calls back the
client and tells something like "For the request you posted, and I
acknowledged to, my response is...".
Happens all the time in business processes... (Gee, and I thought that
_THAT_ job was useless!).
All I can suggest to Joe is to, instead of creating sockets using
java.net.URL, is to create sockets manually using java.net.Socket. There's a
constructor there which might help:
public Socket(InetAddress�addr, int�port, InetAddress�locAddr, int�locPort);
Then just set up your firewall to allow outgoing connections from
locAddr:locPort, and you should be more-or-less set. Just be careful because
only one of these sockets can be created at one time, as they share the same
local port (if I'm not wrong!). So, you'll need a transactional queue (can
be easily written) of outgoing connections, one at a time, slowly,
despooling your responses...
Pier
