I am porting a java application which uses multicast sockets to QNX6.1 (with
J9). Under Windows (with J9) the multicast sockets can be bound to the same
address and port by default. When run under QNX only one socket can be bound
to each port/address combination on each machine. Since the current Java
version 1.3 doesn’t support the settting of SO_REUSEADDR or SO_REUSEPORT
socket option flags I was wondering if it is possible to configure all
sockets to default to reusing port/address combinations? Is this a problem
with J9 not setting intelligent defaults, or does QNX differ in the default
socket options?
–
Russell Kennett
Russell Kennett <russk88@hotmail.com> wrote:
I am porting a java application which uses multicast sockets to QNX6.1 (with
J9). Under Windows (with J9) the multicast sockets can be bound to the same
address and port by default. When run under QNX only one socket can be bound
to each port/address combination on each machine. Since the current Java
version 1.3 doesn’t support the settting of SO_REUSEADDR or SO_REUSEPORT
socket option flags I was wondering if it is possible to configure all
sockets to default to reusing port/address combinations? Is this a problem
with J9 not setting intelligent defaults, or does QNX differ in the default
socket options?
The POSIX spec says that SO_REUSEADDR is off by default, and you’ll find that
the behaviour will be the same for any of the BSDs. The POSIX spec doesn’t
talk about SO_REUSEPORT, but it seems rational that it would be off by default
(since SO_REUSEADDR is).
Microsoft may have made the choice that a multicast socket implicitly has the
SO_REUSEADDR/SO_REUSEPORT set.
-Adam
Further inspection of the MulticastSocket java source used revealed that
they set SO_REUSEADDR when creating the socket, but not SO_REUSEPORT. I read
somewhere that these are often treated the same when applied to multicast
sockets, but the tests I ran indicated that this is not the case under QNX.
I have submitted the problem to IBM’s problem reporting site, so we’ll see
what happens. I sincerely hope they fix it, because my current hack requires
modification of the java source to make an additional native call to
setsockopt. Does anyone know if it is possible to set the default socket
creation flags? ie. to make all subsequent sockets default to SO_REUSEPORT.
I would prefer this workaround to having to use non-standard class
libraries.
Russell
“Operating System for Tech Supp” <os@qnx.com> wrote in message
news:9q702k$40i$2@nntp.qnx.com…
Russell Kennett <> russk88@hotmail.com> > wrote:
I am porting a java application which uses multicast sockets to QNX6.1
(with
J9). Under Windows (with J9) the multicast sockets can be bound to the
same
address and port by default. When run under QNX only one socket can be
bound
to each port/address combination on each machine. Since the current Java
version 1.3 doesn’t support the settting of SO_REUSEADDR or SO_REUSEPORT
socket option flags I was wondering if it is possible to configure all
sockets to default to reusing port/address combinations? Is this a
problem
with J9 not setting intelligent defaults, or does QNX differ in the
default
socket options?
The POSIX spec says that SO_REUSEADDR is off by default, and you’ll find
that
the behaviour will be the same for any of the BSDs. The POSIX spec
doesn’t
talk about SO_REUSEPORT, but it seems rational that it would be off by
default
(since SO_REUSEADDR is).
Microsoft may have made the choice that a multicast socket implicitly has
the
SO_REUSEADDR/SO_REUSEPORT set.
-Adam
“Russell Kennett” <russk88@hotmail.com> wrote in message
news:9qd6vh$i5b$1@inn.qnx.com…
Further inspection of the MulticastSocket java source used revealed that
they set SO_REUSEADDR when creating the socket, but not SO_REUSEPORT. I
read
somewhere that these are often treated the same when applied to multicast
sockets, but the tests I ran indicated that this is not the case under
QNX.
Does the same behaviour not occur under other BSDs (ie. NetBSD). I would be
very surprised if it did not.
Does anyone know if it is possible to set the default socket
creation flags? ie. to make all subsequent sockets default to
SO_REUSEPORT.
I would prefer this workaround to having to use non-standard class
libraries.
No. setsockopt() will allow you to set the options for a particular socket,
but not a default behaviour for all subsequent sockets.
-Adam