Now that my IPs are propagating, I am attempting to convert my existing 4 private Java proxies to your code. Looks like it is working, but I do have some questions to avoid potential issues. The old proxies were defined by IP address - IP addresses are very tightly controlled, because there's a mix of proxies and Echolink conferences running on the one machine.
My program does not listen on individual addresses. It opens a wildcard socket for each port, receives the traffic and gets the addresses from the OS using special system calls. That way it can run serveral proxies and relays using only very few sockets, improving the efficiency of the select().
You can just move over the existing Java proxies to the C program. Stop the Java proxies and add their addresses to the config file of the C program.
I have no experience with conferences, I do not know if they can co-exist on the same machine with the proxies. Probably not. It is probably best to use a separate (virtual) machine for them. However, I am not sure. It could also be that having the software that opens ports at an explicit address and these wildcard ports can co-exist.
Rob
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
Ruben - ON3RVH
On 5 May 2018, at 22:09, Rob Janssen pe1chl@amsat.org wrote:
Now that my IPs are propagating, I am attempting to convert my existing 4 private Java proxies to your code. Looks like it is working, but I do have some questions to avoid potential issues. The old proxies were defined by IP address - IP addresses are very tightly controlled, because there's a mix of proxies and Echolink conferences running on the one machine.
My program does not listen on individual addresses. It opens a wildcard socket for each port, receives the traffic and gets the addresses from the OS using special system calls. That way it can run serveral proxies and relays using only very few sockets, improving the efficiency of the select().
You can just move over the existing Java proxies to the C program. Stop the Java proxies and add their addresses to the config file of the C program.
I have no experience with conferences, I do not know if they can co-exist on the same machine with the proxies. Probably not. It is probably best to use a separate (virtual) machine for them. However, I am not sure. It could also be that having the software that opens ports at an explicit address and these wildcard ports can co-exist.
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Sat, May 5, 2018, 1:37 PM Ruben ON3RVH on3rvh@on3rvh.be wrote:
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
Ruben is this true with 'SO_REUSEADDR'? which I notice in elproxy.c has. With 'SO_REUSEADDR', the way I understand it is that it made "0.0.0.0:8100" and "192.168.0.1:8100" to not be "exactly" the same bind, whether without 'SO_REUSEADDR', "0.0.0.0:8100" and "192.168.0.1:8100" are indeed the same bind since the 0.0.0.0 cover all of 192.168.0.1.
Hey Bao,
I’m not quite sure about that. But it is my understanding with a lot of packages that you cannot bind to 192.1.1.1:53 for example when 0.0.0.0:53 is bound to another service. Same with 127.0.0.1:53
Ruben - ON3RVH
On 6 May 2018, at 08:44, Bao Nguyen ngqbao@gmail.com wrote:
On Sat, May 5, 2018, 1:37 PM Ruben ON3RVH on3rvh@on3rvh.be wrote:
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
Ruben is this true with 'SO_REUSEADDR'? which I notice in elproxy.c has. With 'SO_REUSEADDR', the way I understand it is that it made "0.0.0.0:8100" and "192.168.0.1:8100" to not be "exactly" the same bind, whether without 'SO_REUSEADDR', "0.0.0.0:8100" and "192.168.0.1:8100" are indeed the same bind since the 0.0.0.0 cover all of 192.168.0.1. _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Ruben,
Right with the default bind options that's the expected behavior. However, if each of the software that setup a bind socket with 'SO_REUSEADDR' option, it would mean that each 127.0.0.1:53, 192.1.1.1:53 and 0.0.0.0:53 are individual and unique bind set.
In this case, I believe that if the conference software Tony use also bind with 'SO_REUSEADDR', then it should work with elproxy since elproxy seemed to already use that option. Tony can strace (in Linux) his conference software to find out if it's setup with that option. -bn 0216331C
On Sun, May 6, 2018 at 12:26 AM, Ruben ON3RVH on3rvh@on3rvh.be wrote:
Hey Bao,
I’m not quite sure about that. But it is my understanding with a lot of packages that you cannot bind to 192.1.1.1:53 for example when 0.0.0.0:53 is bound to another service. Same with 127.0.0.1:53
Ruben - ON3RVH
On 6 May 2018, at 08:44, Bao Nguyen ngqbao@gmail.com wrote:
On Sat, May 5, 2018, 1:37 PM Ruben ON3RVH on3rvh@on3rvh.be wrote:
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
Ruben is this true with 'SO_REUSEADDR'? which I notice in elproxy.c has. With 'SO_REUSEADDR', the way I understand it is that it made "0.0.0.0:8100" and "192.168.0.1:8100" to not be "exactly" the same bind, whether without 'SO_REUSEADDR', "0.0.0.0:8100" and "192.168.0.1:8100" are indeed the same bind since the 0.0.0.0 cover all of 192.168.0.1. _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 06/05/18 17:39, Bao Nguyen wrote:
Ruben,
Right with the default bind options that's the expected behavior. However, if each of the software that setup a bind socket with 'SO_REUSEADDR' option, it would mean that each 127.0.0.1:53, 192.1.1.1:53 and 0.0.0.0:53 are individual and unique bind set.
In this case, I believe that if the conference software Tony use also bind with 'SO_REUSEADDR', then it should work with elproxy since elproxy seemed to already use that option. Tony can strace (in Linux) his conference software to find out if it's setup with that option. -bn 0216331C
I suspect it does, because the default configuration binds 127.0.0.1:5198 and 127.0.0.1:5199, as well as 0.0.0.0:5198 and 0.0.0.0:5199. So far, testing seems to indicate this works.
On 06/05/18 06:35, Ruben ON3RVH wrote:
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
The rules don't seem so clear cut for UDP.
On 06/05/18 06:07, Rob Janssen wrote:
My program does not listen on individual addresses. It opens a wildcard socket for each port, receives the traffic and gets the addresses from the OS using special system calls. That way it can run serveral proxies and relays using only very few sockets, improving the efficiency of the select().
I did notice it listens on 0.0.0.0, at least in port 8100.
You can just move over the existing Java proxies to the C program. Stop the Java proxies and add their addresses to the config file of the C program.
Yes, I did get that working. :)
I have no experience with conferences, I do not know if they can co-exist on the same machine with the proxies. Probably not. It is probably best to use a separate (virtual) machine for them.
Not practical.
However, I am not sure. It could also be that having the software that opens ports at an explicit address and these wildcard ports can co-exist.
I have seen that with tbd, which opens 5198 and 5199 UDP on 127.0.0.1 for commands and chat respectively, while the default configuration has Echolink listening on 5198 and 5199 on 0.0.0.0, so there is hope. Will have to test further, though I was able to connect from my new proxy to one of the conferences on the same box.
-
Bao Nguyen -
Rob Janssen -
Ruben ON3RVH -
Tony Langdon