[
https://issues.redhat.com/browse/JGRP-2521?page=com.atlassian.jira.plugin...
]
Bela Ban updated JGRP-2521:
---------------------------
Description:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two
decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the
cache of IP addresses:ports and UUIDs. This requires a poor man's state transfer of
this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-address cache, which already exists in
the transport. When a view change is received, a member simply determines the peer to
which to connect to by grabbing the peer's IP address from the transport cache, and
connecting to it at {{port}}. We probably need a port range, too.
was:
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last two
decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains the
cache of IP addresses:ports and UUIDs. This requires a poor man's state transfer of
this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-address cache, which already exists in
the transport. When a view change is received, a member simply determines the peer to
which to connect to by grabbing the peer's IP address from the transport cache, and
connecting to it at {{port}}. We probably need a port range.
FD_SOCK2
--------
Key: JGRP-2521
URL:
https://issues.redhat.com/browse/JGRP-2521
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Major
Fix For: 5.2
FD_SOCK is quite old and hasn't been given a lot of maintenance love over the last
two decades (2001!).
The code is quite complicated/brittle and could use some simplification.
The major enhancement is to use a fixed port, so we can scrap the code which maintains
the cache of IP addresses:ports and UUIDs. This requires a poor man's state transfer
of this cache to new members, plus update messages whenever a new member starts.
Using a fixed port allows us to reuse the UUID/IP-address cache, which already exists in
the transport. When a view change is received, a member simply determines the peer to
which to connect to by grabbing the peer's IP address from the transport cache, and
connecting to it at {{port}}. We probably need a port range, too.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)