Re: [tcpm] TCP, multiple addresses and soft errors when connecting

[Pekka Savola <[e-mail]>]

On Mon, 5 Apr 2004, Fernando Gont wrote:
> At 09:25 05/04/2004 +0300, Pekka Savola wrote:
> > > >  2) state the desire for getting a better higher-level API which would
> > > >handle all of this and much more (instead of/in addition to 1), but
> > > >mention why this is not an only practical solution.
> > > What do you mean "this is not an only practical solution"?
> >What I should have said if "but mention why this is would not be a
> >practical solution, if there were no other solutions".
> 
> Actually, I think it is the only real solution to the problem.
> Having the API report ICMP errors to the application is moving the problem 
> from the API to the application, but *not* solving it.
>
> If you leave connect() as is, then you may have the delay problem you 
> describe (i.e., you may suffer undesirable delays to use a service).
> If you make it report ICMP errors to the application, you still have a 
> problem I mentioned in the other e-mails. You might even say that you'll 
> have application programmers (probably *not* knowledgeable on TCP/IP 
> internals) handling issues of the underlying protocols.

I have to disagree here.  Writing getaddrinfo() loops which include
loops around socket() and even connect() are commonplace so this is
nothing new.  Actually this was discussed in
draft-ietf-v6ops-application-transition-02.txt which we just shipped
off to the IESG.  Section 6.3.2 gives a specific example and section
6.3 describes alternative means; the user does not -- necessarily --
need to know anything and the coder only needs to know to build the
right logic. (Which is required anyway for proper v6/v4 applications.)

Again, high-level API which makes it smoother to use either v4 or v6 
would not hurt either, and could be achieved in one shot.  But again, 
this is not here and now.

> So a real solution is to hide all this stuff from the application 
> programmer. Let him just concentrate on actually using a service, and 
> handle all the protocol-related issues inside the API.

For long-term, yes, that would be preferable (even though I think 
still there should be low-level equivalents, but not necessarily 
integrated with connect()).

But the problem is that the IETF has avoided specifying APIs whereever 
it has been able to, and even if we made these here (or elsewhere), 
there would have to be significant vendor buy-in (so that they could 
be used to create portable code), and implementation.  Even if there 
would be significant interest, this would take 3 years (minimum).

So, for all the good having such APIs would do, I fail to see how it 
could provide sufficiently short-term fix to this particular problem, 
and which is why we're documenting the connect() semantics change some 
have already done.

> >That is, new APIs would be great, but we cannot stop fixing problems
> >current APIs until we have something more concrete out there.
> >Otherwise we'd end up with no practically (in short term) deployable
> >solution.
> 
> If you consider it useful, I could try to continue thinking on the 
> "abstract" API. I'm just thinking about writting some stuff down, so that 
> there's a place from which which can move things forward. It may take me 
> some time (say, months), but...

I certainly think this is interesting work (actually, I've seen some
abstractization libraries for Unix already a couple of years ago,
doing something like you say -- but I can't find it now; maybe it was
something along the lines of http://thf.ath.cx/snl), but as I stated
above, there are significant barriers to be torn down first..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm