Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) Newsgroups: net.unix-wizards Subject: Re: STREAMS query Message-ID: <2144@brl-tgr.ARPA> Date: Tue, 15-Oct-85 14:17:08 EDT Article-I.D.: brl-tgr.2144 Posted: Tue Oct 15 14:17:08 1985 Date-Received: Thu, 17-Oct-85 02:25:57 EDT Sender: news@brl-tgr.ARPA Lines: 35 >steveg@hammer.UUCP (Steve Glaser) writes >The accept blocks till a connection request is received. It returns >new file descriptor representing the *open* connection. If the server >didn't really want to talk to somebody (say it only accepts conections >from specific users), it would have to close the connection. The >client side has now seen a "connection succeed" followed by a "close >connection". >....4.2 BSD does not support this cleanly. The description seems fine but could someone clarify exactly what the objection is here, with a little more than 'does not support this cleanly'. Is this a religious issue? If a client connects to a server and the server wishes to reject on the basis of some info about the remote side, what is the harm of just tossing the remote side with a shutdown() or close(), (the other side will get offended at its rude treatment?) Or is the real issue here that there is no way to securely determine the USER associated with the client process? If so, I think that is orthogonal to whether you have to accept() to find out. It's a desireable feature that can be layered into applications (consider FTP and TELNET for example.) I think it's semantics, if TP4 is passing that much info it may as well be open, although standardizing rejections analagous to could be an advantage in a few situations (might prevent re-tries, see SMTP for a model of this, fatal, temporary etc rejections.) In fact, errno.h probably covers just about everything one might want to say, a few could be added with little harm (we are not *yet* threatening errno's 2^32 address space! :-) I presume that even in heterogenous nets most systems on the net support the notion of an integer, so the idea is portable, adapting to SMTP's format of "errno string" should be a fine way to explain to the other side why they are getting 86'd. -Barry Shein, Boston University