neerma@COD.NOSC.MIL.UUCP (07/09/87)
We have several IBM ATs(and compatibles) on an Ethernet along with SUN terminals . We are developing network code on the ATs to interface with Network Research's FUSION TCP package. Basically the AT act as servers. To test our servers we hav e client programs on the SUNs. The server ATs send data to the Suns as fast as the TCP can accept it. Since the client on the SUN is relatively slow(scrolling data to SUN screen) TCP's flow control mechanism is invoked. The problem is that at some point the AT will stop sending data for long periods of time(on the order of minutes). Using a netmonitor program the packet trace reveals the following phenomena: the SUN TCP apparantly ACKs the same data 'bokoo' times; that is the trace shows at some times the SUN is the only one generating packets the packets are TCP only packets(no data) the ACK and SEQ #s are the same on all the packets, the AT is sending nothing in response, the SUN fills up a couple of screens with these, the AT comes to a screeching halt. The packets from the SUN show a large window being advertised yet no data comes from the AT. After several minutes the AT seems to 'wake up' and start sending again. From the netmonitor viewpoint it looks as though the SUN inundates the AT with ACKs; the AT gets uptight and refuses to send any data for a while. It seems the SUN is misbehaving by ACKing data more than once. Since the data field is 0 and only the ACK flag is on it seems the only purose of these packets is to ACK data but maybe I'm missing something. Maybe its trying(correctly) to open a window. (If so, taking a RAMBO approach). The AT by the way has a 3COM 505 interface to the ethernet. Another problem we have seen during this developement are what I would call silly windows being advertised by the SUN. Do SUNs still suffer from this problem? I thought this was done away with long ago? Merle Neer NOSC ------- -------