Dear Users,
New line in stunnel 4.06 ChangeLog: - Multiple connect=host:port options are allowed in a single service section. Remote hosts are connected using round-robin algorithm.
What do you think?
Best regards, Mike
New line in stunnel 4.06 ChangeLog:
- Multiple connect=host:port options are allowed in a single service
section. Remote hosts are connected using round-robin algorithm.
What do you think?
Same could be achieved via round-robin dns, where 'mail.example.com' has multiple IP addresses (assuming you delay DNS checks rather than caching it the first time.)
But that assumes you have control of a DNS server so you can do this if you wanted to load balance between mail.example.com and pop.example.net. Using your own dns you can do this, but if you don't have a DNS server you control, your proposed change would do the trick.
So I say "if it doesn't add to the code complexity or add security problems, by all means.
On Oct 14, 2004, at 5:29 PM, Brian Hatch wrote:
Same could be achieved via round-robin dns, where 'mail.example.com' has multiple IP addresses (assuming you delay DNS checks rather than caching it the first time.)
Not exactly the same. With DNS you can only connect single port on several machines. DNS configuration is also more complicated and requires administrator privileges.
Best regards, Mike
At 17:16 14.10.2004, Michal Trojnara wrote:
Dear Users,
New line in stunnel 4.06 ChangeLog:
- Multiple connect=host:port options are allowed in a single service
section. Remote hosts are connected using round-robin algorithm.
What do you think?
Sounds cool :)
By the way, another suggestion from my practical experience: STunnel caches DNS query results, this is a bad idea when using services like dyndns.org... I've have numerous occasions where I had to whip out my command shell and net stop stunnel | net start stunnel to get the DNS resolution updated to reach my remote server on dynamic IP... Over here in germany, a lot of DSL lines have forced disconnect after 24 hrs online time (I heard that's due to the structure of their billing systems and can't be changed without dramatic amounts of work and money) so every time my remote computer gets disconnected, I have to restart STunnel here. I'd suggest to make DNS caching configurable. If the user wishes so, keep the cached DNS info, otherwise resolve host names each time a connection is established (or every xx minutes or whatever).
Best regards, Andre
On Oct 14, 2004, at 6:32 PM, Andre Tertling wrote:
I'd suggest to make DNS caching configurable. If the user wishes so, keep the cached DNS info, otherwise resolve host names each time a connection is established (or every xx minutes or whatever).
Since stunnel 4.00 you can use "delay=yes" to enable delayed resolver. 8-)
Best regards, Mike
Hi Michal,
I'd suggest to make DNS caching configurable. If the user
wishes so,
keep the cached DNS info, otherwise resolve host names each time a connection is established (or every xx minutes or whatever).
Since stunnel 4.00 you can use "delay=yes" to enable delayed resolver. 8-)
Umm, what exactly does that option do? My problem is that STunnel does not resolve hostnames every time a connection is established (at least it seems like that), instead it remembers the previously valid IP for that hostname... (Which now is invalid due to a newly assigned IP.)
Best regards, Andre
Dear Users,
New line in stunnel 4.06 ChangeLog:
- Multiple connect=host:port options are allowed in a single service
section. Remote hosts are connected using round-robin algorithm.
Great feature!!!
I assume that in the case of "bad remote host" the client will select the next configured server..
That would actually be perfect for both simple load-sharing and a very simple solution to handle broken remote stunnel servers..
For loadsharing it could be interesting to have the initially selected server in the list chosen randomly if possible..
Regards
/Sqm
What do you think?
Best regards, Mike
stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
SqM wrote:
I assume that in the case of "bad remote host" the client will select the next configured server..
If "bad remote host" means that connect() has failed - yes.
That would actually be perfect for both simple load-sharing and a very simple solution to handle broken remote stunnel servers..
Right. So you gain both: performance and reliability.
For loadsharing it could be interesting to have the initially selected server in the list chosen randomly if possible..
You mean that each client makes its first connection to the same host, right? You could randomize the order of "connect" options in configuration files distributed to clients.
Best regards, Mike
SqM wrote:
I assume that in the case of "bad remote host" the client will select the next configured server..
If "bad remote host" means that connect() has failed - yes.
That would actually be perfect for both simple load-sharing and a very simple solution to handle broken remote stunnel servers..
Right. So you gain both: performance and reliability.
For loadsharing it could be interesting to have the initially selected server in the list chosen randomly if possible..
You mean that each client makes its first connection to the same host, right? You could randomize the order of "connect" options in configuration files distributed to clients.
Yep.. But.. I would preffer to have the same config on all clients.
But still.. This function sounds great and will at least help me!
/Uffe
-
Andre Tertling -
Brian Hatch -
Joerg F. Wittenberger -
Michal Trojnara -
Michal Trojnara -
SqM -
Uffe Vedenbrant