From owner-cvs-all Thu Jun 15 12:48:11 2000 Delivered-To: cvs-all@freebsd.org Received: from exchange.accessus.net (exchange.accessus.net [207.206.171.65]) by hub.freebsd.org (Postfix) with ESMTP id 8A0E937C3FF; Thu, 15 Jun 2000 12:47:58 -0700 (PDT) (envelope-from jyoung@accessus.net) Received: by exchange.accessus.net with Internet Mail Service (5.5.1960.3) id ; Thu, 15 Jun 2000 14:50:28 -0500 Message-ID: From: Jason Young To: 'Alfred Perlstein' , Nate Williams Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: RE: cvs commit: src/sys/kern uipc_socket.c uipc_socket2.c src/sys /sys socket.h Date: Thu, 15 Jun 2000 14:50:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Also, I *really* don't like the accept() changes, since we > (and a number > > of others) are currently taking advantage of the fact that > we can 'ping' > > a host by contacting a known port and if accepts the > connection, which > > we subsuquently close. > > > > ICMP is often filtered, but in our equipment (which happens to be > > installed the customer's site), we run a the 'echo' port for our > > internal ping. > > > > Waiting until data is sent (or received) is a bad thing, IMO, and > > probably violates the TCP specifications. > > That's not what the code does, nothing funky happens with TCP > connections, the socket is accepted, however it is not presented > to the application until data arrives. I think perhaps Nate is under the impression that it's a global change for all connections, whereas it's really a new and non-default socket option if I understand correctly. The impact is that an application which does not need to present a "banner" (SMTP requires one, for instance) can defer being woken up until it actually has work to do, and other applications are untouched. I think both kblob and the new socket options are great ideas myself, but I have about zero votes in this whole affair. I would think that a mechanism to give the kernel a pattern to look for instead of only looking for HTTP requests would be nice, but I'm not sure if a useful mechanism could be developed without trying to install regexp processing in the kernel. Jason Young Access US Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message