From owner-freebsd-hackers  Wed Nov 13 13:06:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA16243
          for hackers-outgoing; Wed, 13 Nov 1996 13:06:39 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA16219
          for <hackers@freebsd.org>; Wed, 13 Nov 1996 13:06:29 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA22868; Wed, 13 Nov 1996 13:54:55 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199611132054.NAA22868@phaeton.artisoft.com>
Subject: Re: Programming technique for non-forking servers?
To: carson@lehman.com
Date: Wed, 13 Nov 1996 13:54:54 -0700 (MST)
Cc: terry@lambert.org, stesin@gu.net, hackers@freebsd.org,
        squid-users@nlanr.net, basch@lehman.com
In-Reply-To: <199611132028.PAA18081@dragon.lehman.com> from "carson@lehman.com" at Nov 13, 96 03:28:39 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 3) getpeername()
> 
> Works everywhere, but looses the connect error...
> 
> Oh, and don't forget that sometimes connect() will return immediately, even
> if the socket is non-blocking, so you have to check for all possible states
> (success, non-blocking, or error). And be carefull, connect() can return
> different values for non-blocking on different OS's (EINPROGRESS,
> EWOULDBLOCK, etc.)

If you are running a server, then the event *must* be that the data
*is* available.

Therefore you should *always* use blocking sockets.

I think the async connect is not an issue, since as a server, all
connections are *inbound*, not outbound.  You use "accept", not
"connect".


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.