2:48 a.m.
Allow 0.0.0.0 as bind address
-----------------------------
Key: JGRP-1268
URL: https://issues.jboss.org/browse/JGRP-1268
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
Currently, bind_addr has to be a valid interface and the wildcard (0.0.0.0) address is not
permitted. The reason is that bind_addr determines the physical address of a node, e.g.
192.168.1.5:46537, and using 0.0.0.0:46537 wouldn't allow us to identify the node in
order to send it a message.
To allow for TCP and UDP sockets to bind to the wildcard address, we could either use a
bind_addr of 0.0.0.0 and introduce an additional property to pick the physical address
(e.g. physical_addr="192.168.1.5" / physical_addr="GLOBAL"), or
continue using bind_addr to determine the physical address and add a property
(bind_to_wild_card_addr="true") to make the UDP and TCP sockets bind to the
wildcard address (if true).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:18 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1268) Allow 0.0.0.0 as bind address
[
https://issues.jboss.org/browse/JGRP-1268?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1268:
--------------------------------
[comment by Jayesh Seshadri]
What would be the address visible to other entities (i.e. where would
they send their packets to)?
Note that currently if you use the external address 'override' for
that, jgroups resolves the external_addr property using
InetAddress.getByName on the node that the external_addr was assigned
to, prior to advertising that address to the peers.
A simple fix would be to skip that resolution on the node that the
external_addr is assigned and simply advertise the supplied
external_addr string as-is to the other nodes, requiring that to be
resolvable from the other nodes. So if I set external_addr =
'foobar.corp.com', peers would get the peer address as
"foobar.corp.com", and attempt to send packets to "foobar.corp.com",
instead of the single IP returned by InetAddress.getByName().
Allow 0.0.0.0 as bind address
-----------------------------
Key: JGRP-1268
URL: https://issues.jboss.org/browse/JGRP-1268
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
Currently, bind_addr has to be a valid interface and the wildcard (0.0.0.0) address is
not permitted. The reason is that bind_addr determines the physical address of a node,
e.g. 192.168.1.5:46537, and using 0.0.0.0:46537 wouldn't allow us to identify the node
in order to send it a message.
To allow for TCP and UDP sockets to bind to the wildcard address, we could either use a
bind_addr of 0.0.0.0 and introduce an additional property to pick the physical address
(e.g. physical_addr="192.168.1.5" / physical_addr="GLOBAL"), or
continue using bind_addr to determine the physical address and add a property
(bind_to_wild_card_addr="true") to make the UDP and TCP sockets bind to the
wildcard address (if true).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:23 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1268) Allow 0.0.0.0 as bind address
[
https://issues.jboss.org/browse/JGRP-1268?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1268:
--------------------------------
Hmm, not so sure this makes sense...
Even if a user can set the bind address to be 0.0.0.0, at the end of the day they still
have to pick an address (e.g. external_addr) that's going to be advertized as the
node's address. So we're just pushing the issue of picking an address from
bind_addr to external_addr. If we have to pick an address, might as well pick it for
bind_addr (as is currently the case).
Comments ?
Allow 0.0.0.0 as bind address
-----------------------------
Key: JGRP-1268
URL: https://issues.jboss.org/browse/JGRP-1268
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
Currently, bind_addr has to be a valid interface and the wildcard (0.0.0.0) address is
not permitted. The reason is that bind_addr determines the physical address of a node,
e.g. 192.168.1.5:46537, and using 0.0.0.0:46537 wouldn't allow us to identify the node
in order to send it a message.
To allow for TCP and UDP sockets to bind to the wildcard address, we could either use a
bind_addr of 0.0.0.0 and introduce an additional property to pick the physical address
(e.g. physical_addr="192.168.1.5" / physical_addr="GLOBAL"), or
continue using bind_addr to determine the physical address and add a property
(bind_to_wild_card_addr="true") to make the UDP and TCP sockets bind to the
wildcard address (if true).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-1268) Allow 0.0.0.0 as bind address
[
https://issues.jboss.org/browse/JGRP-1268?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1268.
----------------------------
Resolution: Rejected
As per my last comment. Re-open if needed
Allow 0.0.0.0 as bind address
-----------------------------
Key: JGRP-1268
URL: https://issues.jboss.org/browse/JGRP-1268
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
Currently, bind_addr has to be a valid interface and the wildcard (0.0.0.0) address is
not permitted. The reason is that bind_addr determines the physical address of a node,
e.g. 192.168.1.5:46537, and using 0.0.0.0:46537 wouldn't allow us to identify the node
in order to send it a message.
To allow for TCP and UDP sockets to bind to the wildcard address, we could either use a
bind_addr of 0.0.0.0 and introduce an additional property to pick the physical address
(e.g. physical_addr="192.168.1.5" / physical_addr="GLOBAL"), or
continue using bind_addr to determine the physical address and add a property
(bind_to_wild_card_addr="true") to make the UDP and TCP sockets bind to the
wildcard address (if true).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5083
days inactive
5120
days old
3 comments
1 participants
participants (1)
-
Bela Ban (JIRA)