Add simple HOSTID and port-number retention support #163
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
May 1, 2025 16:10
In order for `bore to be employed by large number of embedded devices, a series of changes is needed. First, a specific host-ID string is necessary to query on the server side, to fetch the port number for a given embedded device: netcat -w 1 127.0.0.1 10088 client[0] => hostid: dev_ubuntu, online: true, portno: 15921, last_dance: 1746084941, discon: 4 client[1] => hostid: dev_raspbe, online: true, portno: 10846, last_dance: 1746085815, discon: 1 Secondly, heartbeat messages from `bore server should be minimized to reduce TCP/IP traffic for embedded devices, as it might not have inexpensive internet connections. Interval (in seconds) for heartbeat messages can be changed via setting environment variable `BORE_HEARTBEAT_INTERVAL, which defaults to 180 seconds. Thirdly, as intervals between heartbeat have been greatly increased, TCP KeepAlive settings are supported to enable proper detection of closed TCP connections. Intervals for TCP-KeepAlive packages can be modified by setting environment variable `BORE_KEEPINTERVAL, which defaults to 120 seconds. The remaining problem is that, `bore server cannot detect fast reconnection from clients, port-number reusing is very likely to fail in such scenario.
The commit resolves the problem that previously occupied port cannot be easily freed, a newly connected client with identical `hostid has to bind to another port number. Also, the commit requires that `hostid string from clients cannot be empty. If `hostid is not specified, an random string will be generated.
MrG9090
approved these changes
May 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order for `bore to be employed by large number of embedded devices, a series of changes is needed. First, a specific host-ID string is necessary to query on the server side, to fetch the port number for a given embedded device:
netcat -w 1 127.0.0.1 10088
client[0] => hostid: dev_ubuntu, online: true, portno: 15921, last_dance: 1746084941, discon: 4 client[1] => hostid: dev_raspbe, online: true, portno: 10846, last_dance: 1746085815, discon: 1
Secondly, heartbeat messages from
bore server should be minimized to reduce TCP/IP traffic for embedded devices, as it might not have inexpensive internet connections. Interval (in seconds) for heartbeat messages can be changed via setting environment variableBORE_HEARTBEAT_INTERVAL, which defaults to 180 seconds.Thirdly, as intervals between heartbeat have been greatly increased, TCP KeepAlive settings are supported to enable proper detection of closed TCP connections. Intervals for TCP-KeepAlive packages can be modified by setting environment variable `BORE_KEEPINTERVAL, which defaults to 120 seconds.
The remaining problem is that, `bore server cannot detect fast reconnection from clients, port-number reusing is very likely to fail in such scenario.