Hi Malcolm, On Fri, Jul 24, 2009 at 12:15:29PM +0100, Malcolm Turnbull wrote: > > I definitely see a problem. Timeouts are too short for RDP (50 seconds). So > > after that time, if the client does nothing (eg: talk on the phone), his > > session expires. From what I've heard, people tend to set session timeouts > > between 8 and 24 hours on RDP. > > Windows RDP clients send a keepalive every minute and have seemless > reconnection's which probably hides the problem a bit
I wasn't aware, so yes that's really nice, especially with persistence ! > (Linux clients crash after 50 seconds) , so yes massive timeout makes a > lot of sense. Yes, I have memories of rdesktop dying with an error message. Maybe there are options for automatic reconnection, but I haven't looked. > > BTW, you might be very interested. Exceliance has developped and contributed > > RDP persistence ! This is in the development branch. Check the latest > > snapshot > > here : > > > > http://haproxy.1wt.eu/git/?p=haproxy.git > > > > basically, you just have to add the following statement in your backend : > > > > persist rdp-cookie > > > > Thats fantastic news! Really looking forward to that one.... If you have means to give it a try, please download the development version (1.4-dev0 snapshot from the gitweb interface). > But has any one looked at doing a SourceIP persistence which is not a > hash i.e. a look up table of source IPs? We wanted to work on it but don't have the time to do everything, so... one thing at a time :-) > The maintenance of real servers is almost impossible in hash > mode...without users on RDP (or other TCP app.) hitting the wrong > server. yes, I know. I would also like to implement a dual source hash LB mode. It would do the following : - hash source => X, divide by total number of servers, returns Y [0..nbsrv-1] - if server Y is down, then divide X by number of available servers, return Z [0..nbsrvup-1], and use server Z. That way, if you lose a server, only this server's clients are redispatched, the other ones remain unaffected. This is only true when all servers are up and we lose one. Because if only half the servers are up and you lose one, about half of the users will move since they're already on the second hash. A smarter method would consist in rehashing without the last server as long as we get a DOWN server. But it would consume huge amounts of CPU for each request and would probably not be much useful anyway. At first glance, the algorithm looks very simple, but when you take into account the fact that there are already 2 weighted arrays (active and backup), it becomes less obvious how to implement this (we need 4 arrays now). So we'll keep that for a later version. > I might play with the aformentioned trick in the meantime though: > server TS-1 10.0.0.102 check port 3300 > server TS-1 10.0.0.102 check port 3389 backup > > I guess another option with maintenance is to allow a server weight of > 0 (offline for maintenance) It's allowed now. It will be in version 1.3.19 tomorrow and it's already in development version. And yes, it helps a lot, since it still supports persistence (eg: for soft maintenance mode in HTTP). > and have two options for this: > 1) Kill all connections immediately and move to new server. > 2) Wait for old connections to timeout, and new connections go to new server. you can do that when you restart haproxy with the new configuration, #1 is done with "-st $oldpid", and #2 is done with "-sf $oldpid". Regards, Willy
