Re: [tae] The internet architecture

Keith Moore <moore@network-heretics.com> Fri, 05 December 2008 16:29 UTC

Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022483A6B05; Fri, 5 Dec 2008 08:29:35 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825523A6B08 for <tae@core3.amsl.com>; Fri, 5 Dec 2008 08:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcMqBUZeUSqP for <tae@core3.amsl.com>; Fri, 5 Dec 2008 08:29:32 -0800 (PST)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id D72BD3A6ABA for <tae@ietf.org>; Fri, 5 Dec 2008 08:29:32 -0800 (PST)
Received: from lust.indecency.org (adsl-242-100-137.tys.bellsouth.net [74.242.100.137]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BFC33978 (AUTH admin@network-heretics.com) for tae@ietf.org; Fri, 5 Dec 2008 08:29:25 -0800 (PST)
Message-ID: <493956E3.4010004@network-heretics.com>
Date: Fri, 05 Dec 2008 11:29:23 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: John Day <jeanjour@comcast.net>
References: <C15AE32B-E564-4C93-86FF-40EF203E673A@mpi-sws.org> <49382030.5020704@network-heretics.com> <200812051425.mB5EPKEG032766@cichlid.raleigh.ibm.com> <a06240844c55ef6a022e1@[10.0.1.34]>
In-Reply-To: <a06240844c55ef6a022e1@[10.0.1.34]>
Cc: Thomas Narten <narten@us.ibm.com>, tae@ietf.org, ietf@ietf.org, Bryan Ford <brynosaurus@gmail.com>
Subject: Re: [tae] The internet architecture
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org

John Day wrote:
>>
>> Wouldn't it have been nice if the de facto APIs in use today were more
>> along the lines of ConnectTo(DNS name, service/port).
> 
> That had been the original plan and there were APIs that did that. But
> for some reason, the lunacy of the protocol specific sockets interface
> was preferred.  

About the time I wrote my second network app (circa 1986) I abstracted
all of the connection establishment stuff (socket, gethostbyname, bind,
connect) into a callable function so that I wouldn't have to muck with
sockaddrs any more.  And I started trying to use that function in
subsequent apps.  What I generally found was that I had to change that
function for every new app, because there were so many cases for which
merely connecting to port XX at the first IP address corresponding to
hostname YY that accepted a connection, was not sufficient for the
applications I was writing.  Now it's possible that I was writing
somewhat unusual applications  (e.g. things that constrained the source
port to be < 1024 and which therefore required the app to run as root
initially and then give up its privileges, or SMTP clients for which MX
processing was necessary) but that's nevertheless what I experienced.

These days the situation is similar but I'm having to deal with a
mixture of v4 and v6 peers, or NAT traversal, or brain-damage in
getaddrinfo() implementations, or bugs in the default address selection
algorithm.

With so much lunacy in the how the net works these days, I regard a
flexible API as absolutely necessary for the survival of applications.

Keith
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae