[ On Fri, November 13, 1998 at 12:13:38 (-0800), Marc Slemko wrote: ]
Subject: Re: other network problems with hosts at internic.net
This same thing is happening to me, but in my case it is a bug in the InterNIC's whois server that must have just been introduced recently.
I have the same problem contacting their web server, and sometimes even with telnet and ftp to their servers.
AFAIK, the whois protocol is supposed to consist of a request terminated by a '\n'. However, the InterNIC's server is sending a response as soon as it gets the first packet, even if there is no \n termination.
The NetBSD whois client uses stdio, and sends the last argument with a single fprintf() call followed by an fflush(). BTW, the NetBSD client sends "\r\n" on the end of the data sent to the server.
There is at least one common whois replacement client that sends the \n in a separate packet. What happens is the first packet with the request but without the \n arrives at the InterNIC, then they send a response and close the socket. In the meantime, the second packet from the client with the \n in arrives after the socket is closed for reading, prompting a RST from the server. Even though the full response is either in socket buffers at the InterNIC or on the wire or even in socket buffers on the client, once the RST arrives that response will be (correctly) thrown away if it hasn't been actually read() by the client.
The exact same whois.c client code running on my NetBSD-1.3.x boxes fails to retrieve the complete response, yet when run on at least the BSDI 1.1 box it works fine.
The reason you see part of it is that the whois server is sending separate packets for the "\nRegistrant:\n" part and the rest of the response.
The fix is for the InterNIC to fix their whois server to conform to the "protocol" and/or do a lingering close so it doesn't send a RST. Simply waiting for the end of the line should be enough and should be correct, although if they really want to do a lingering close then see the lingering_close() function in Apache for an example.
That might indeed help, but I'm not going to put the blame on them immediately since I know that even when I make the connection from my NetBSD boxes the packets are making it back as far as the machine on the far end of my PPP link. The only apparent difference between connections that work, and connections that don't, for me at least, is the initial window size. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>