Re: once again about server port ranges

Dion Picco <[email protected]>
Newsgroups gmane.comp.corba.orbacus
Organization IONA | Making Software Work Together TM
Message-ID <[email protected]>
Hi Alexander,

On Mon, Sep 27, 2004 at 03:26:13PM +0400, Alexander Taranov wrote:
> Some 2 years ago Brent Eagles wrote about subj:
> 
> 
> Just to make sure we are all on the same page... we are talking about 
> specifying a range of 'listening' port numbers, correct?  If so, your 
> cries have been heard.  I'll pass this along for consideration in future 
> releases.  The trick will be in making everybody happy with the fringe 
> conditions, for example:
> 
> * What happens when a server is launched and the ports in the range are 
> exhausted?
> 
> * How much startup overhead is acceptable?  Presumably the whole pool 
> must be searched to find a usable port number.  If the range is large, 
> this may take a few moments.
> 
> * How will this work with the IMR?  I don't know that there would be any 
> issues, but it is something that would need to be looked at.
> 
> Please note that even though the port numbers are constrained for the 
> servers in the 'pool', object references referring to objects hosted in 
> those servers would not be considered persistent since their port 
> numbers could change across process lifetimes.
> 
> Best regards,
> 
> Brent
> 
> So if i understand right the situation is following:
> 
> 1. I can control (-OAPort) listening port number of object adapter.
> 
> 2. When client call particular service associated with this POA
> he(client) is getting _another_ port number to connect to
> 
> 3. This second port number is out of my control
> 
> 4. Ergo my corba server cannot serve over firewall??
> 
> Regards,
> Alexander


Yes you are right on points 1 to 3 (although on point 3 I believe it is
still possible to bind to a particular port, most applications simply
let the OS decide on a free port).  However you are mistaken on point 4.
When the client calls a particular service using the listening port, the
server 'accept's this connection request and creates a new socket bound
to a randomly chosen port.  This is typical of any TCP socket-based
connections.  Normally a firewall is configured to allow any outgoing
traffic but restrict incoming traffic.  Since your server chooses the
port, it is the same as if it had initiated this connection and is
treated as outgoing traffic.  
In other words, a typical firewall will allow that communication to 
take place since you accepted that connection.  This is what happens 
with a webserver.  You make your request over port 80, the server 
accepts it and binds the connection to a new port; the data is then 
transferred over this new port even though only port 80 is open to 
receive incoming traffic.  

Some corporates however disable all outgoing connections except for
specific ports.  This is to restrict their employees from connecting to
FTP servers, Instant Messaging clients, IRC, etc.  In these situations
you could have problems since all traffic is essentially restricted from
your server.  A typical accept call won't reuse port 80 for example
since most ports < 1024 are reserved.  

In any case, as long as your firewall is configured typically, you
should have no problems.

> 
> _______________________________________________
> OB-Users Mailing List - [email protected]
> http://mail.ooc.nf.ca/mailman/listinfo/ob-users
> Visit our support FAQ before you send a message.
> http://www.orbacus.com/faq/support.html

-- 
Dion Picco, Software Engineer
IONA Technologies Inc.
Team Orbacus - Your CORBA Source
mailto:[email protected]
http://www.orbacus.com
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.