max persistance time?

[Joseph T. Duncan]

>> (tcp 1day, tcpfin 1day) cause even if connection is closed correctly the 
>> users real server sesion can still be a running..
>
> hmm, don't understand this. You're not talking about the client launching a 
> job and then disconnecting?

on the real server, the client is given a windows desktop and they can 
have multiple applications running..

the following situations can happen to end the tcp exchange between client 
and real server

a) logout of the real server, real server then closes all of their 
applications, stops their desktop session from running and correctly does 
a finack packet exchange ending the session.

(if the client reconnects they can be balanced(directed) to any real 
server since they don't have a desktop+applications running on any real 
server)

b) 'disconnect' (windows option) from the real server, the realserver puts 
their session in a disconnected state. Their desktop and application are 
still running. a finack packet exchange happens ending that tcp 
connection. After 10 minutes the realserver auto-logs off any 
'disconnected' sessions, shuts the applications down and kills the 
desktop, this time can be adjusted.

(if the client reconnects in this 10 minute window, the director should 
point them back at their disconnected session. the real server will then 
give them their running desktop and applications back.

if the client reconnects after the 10 minute window, the director should 
balance them as a new session since they no longer have a 
desktop+applications running on any real server )

c)The client shuts down and/or closes inappropriately the real server sits 
there, leaves the desktop and applications active. now here is were 
weirdness happens.

In testing if the client computer is a linux box and is still accessible 
the real server will close out the connection(broken connection tcp 
handshake attempt? handled correctly?)

In testing if the client computer is any of windows xp workstations my 
department maintains, is still accessible or becomes accessible later 
(reboot, powered down and then back on later, etc) the real server will 
close out the connection(broken connection tcp handshake attempt? handled 
correctly?)

If the client computer is the weird 1/3 of my customers 
home/office/whatever computer (ones with who knows what on them, or how 
they are configured) the desktop+apps just sit there running on the real 
server no closing of the connection happens.. (failer of some kind, wacko 
config? I don't know I cant really reproduce it, maybe they have some weird 
retarded personal router appliance at home???) real server kills off the 
active (but idle) desktop+applications in 1 day (there is a active but idle 
session autologout after x time setting on the real servers) these clients 
are the troublesome ones cause if they login a few times they will wind up 
with a active but idle desktop+application session on each real server

if the client computer (either testing or customers) does not turn back on 
and/or has no network connectivity. the desktop+apps just sit their active 
but idle tell they hit the 1 day auto logoff

d)If a client computer leaves their session active but idle (ie leaves 
stuff running but goes home for the weekend) then their session is killed 
by the 1 day auto logoff (this is the reason for setting a 1 day 
auto-logoff, so a client can go away for a day but still have stuff 
running if they choose to leave their session running on a work/home 
computer)

*some of these issues would be addressed by l7 balancing but currently the 
only commercial products that can do l7 balancing cost big $$$. their is a 
'free' l7 balancing client (for terminal server traffic only). however it 
requires you to use their proprietary client... which means I would not be 
able to allow macs or linux boxes to connect and would have to train users 
to use the proprietary client. (the majority of my customers just use 
whats available on their computer already since they are 90% winders users 
and have the winders client already installed per default)*

*my customers = faculty, staff, and students at the university I work for*

>> if yes, where is the approprate place to put that setting so if a reboot 
>> (hopefully wont ever happen, unless a kernel change takes place)
>> this setting gets restored auto-magicly?
>
> presumably you have ipvsadm run from an init script when you boot the 
> computer?
(this is a debian stable box)

ipvsadm is started from a linked init script in /etc/rc2.d 
it loads its saved rules from /etc/ipvsadm.rules

so can I place --set x y z in /etc/ipvsadm.rules? this didn't seem 
appropriate cause ipvsadm wont dump the change their when it rewrites that 
file upon a shutdown.

should I edit the init script then or is their a more correct place?


thanks!!!!!

-joseph
_________________________________________________________________________
Info:                           Email:
Joseph T. Duncan                duncan at engr.orst.edu
109 Kidder Hall
Corvalis Or 97333