dnwcv@dcatla.UUCP (William C. VerSteeg) (02/04/88)
I am testing a new terminal server and have run into a problem with TCP windows closing. I have noticed that SUN Unix 4.2 rel3.2 doesn't open its TCP window without prompting. If the SUN closes its window, and it stays closed long enough for a few "polling" packets to pass by, data flow ceases. The window stays closed until a rather long timer on the terminal server expires and it sends another short exploratory packet. This causes aggravating data stoppages. Is this closed window scenario common? Would it be advisable to reduce the terminal server's timer length from 2 minutes to something like 10 seconds? Thanks in advance Bill VerSteeg
bzs@BU-CS.BU.EDU (Barry Shein) (02/04/88)
Get in touch with Sun software service, they've been distributing a fix for that for a while now. It exists in 3.4 also. Not all systems prompt it but we ran right into it with tn3270. -Barry Shein, Boston University
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (02/04/88)
Date: 3 Feb 88 19:18:16 GMT
From: dcatla!dnwcv@gatech.edu (William C. VerSteeg)
Is this closed window scenario common? Would it be advisable to reduce the
terminal server's timer length from 2 minutes to something like 10 seconds?
My opinion is that the terminal server should know little if anything
that it is talking to a TCP stream as opposed to any other kind of
stream. It should be the stream's (TCP in this case) responsibility to
let the program (the terminal server in this case) let one more byte
pass through (because that is how TCP works) which will get the flow of
data working again. Under this scenario, you needn't change the
terminal server, only the variable that controls the timeouts for all of
TCP.
Another opinion is that when the TCP data receiver has acknowledged all
the data yet still offers a zero window, the sender should be allowed to
send the one byte probe immediately, instead of having to wait for a
timer to go off. Again, this is at the TCP stream level, not at the
level of any program.