[omniORB] omniNames and SO_REUSEADDR (on Windows)?

[Martin Ba]

Hi!

To my (uneducated) surprise I noticed that omniNames will quite happily 
bind to the same local 2809 port multiple times, as long as it uses a 
different status file.

The request then will go to a random (or the last started?) omniNames 
process. Obviously, this will cause confusion, if this is ever deployed, 
as object references registered with the first service cannot be seen 
through the second service.

SO_REUSEADDR is hardcoded for `fixed_port` in 
`src\lib\omniORB\orbcore\tcpSocket.cc` so this behavior will affect all 
processes running omniORB on a fixed port.


QUESTION: Why does omniORB specify SO_REUSEADDR at all in this way? What 
would be the point to generally serve the same *fixed* port from 
multiple processes?

QUESTION: As far as I can tell, this behavior never makes sense for 
omniNames???


SPECULATION: Since tcpSocket.cc does not contain Win32 specific code on 
this code path, I'm inclined to suspect that the 
fixed_port/setsockopt(SO_REUSEADDR) call is trying to provide the BSD 
behavior (as elaborated here: 
https://stackoverflow.com/a/14388707/321013) or possibly trying to work 
around the TIME_WAIT issue. I'm the first to admit I understand only 
half of this, but I find it useful to include this background here.


Side Note: The practical problem I have is that we are migrating from a 
solution running omniORB 4.1.2 to 4.2.3 where omniNames will implicitly 
use a different "dat" file, thus making it more likely for a stray 
omniNames process (we start it implicitly with our app - not that much 
CORBA processes around) to mess up communications. I guess it won't be 
that big of a deal in practice.

cheers,
Martin