[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 16:39 20/03/2004 +0200, Pekka Savola wrote:

> Does it really make sense to handle the whole connection establishment
> issue inside the app, instead of inside the API itself?
Those are the core APIs we have today.  We could have better ones, but
IMHO I think we need to fix problems in the current ones as long as we
don't have a widely-deployed alternative.

IMHO, there are two points to note:

* If you fix the current ones so that their behavior is "acceptable" to the application programmer, then it'll be harder to introduce a new API. People is reluctant to change, so they must have a reason for learning a new API. If you try to fix the current one, they will find fewer reasons for the change.

* You said "we don't have a widely-deployed alternative". Unless you meant "we don't have a well-tested alternative", I'd say that it's a chicken-and-egg problem. That means, for an API to be widely deployed, people would have to use it. And for people to use it, they should be able to find a good reason to do it.

Yes, I'm aware that my proposal my sound as a long-term solution. But, IMHO, it will certainly be harder to introduce a new API if you actually want to do it "in long term".
I guess "timing" is an issue, here.



> I think that if we're debating this, we're implicitly assuming that
> applications want to connect to say www.example.com, and not one specific
> IP address to which it maps to.
>
> So why not implement such a "higher-level" connect(), and handle all the
> relevant issues inside the API?

Defining such APIs is probably beyond the scope of the work we can do,
and the things we can fix except in the 5+ year timeframe.. but if I
get you right, you're proposing that instead of:

 1) getaddrinfo() or gethostbyname() and connect for one address,
[where, arguably, TCP retry timeout could be warranted -- I don't
think so myself, but you could argue for it]

 2) getaddrinfo() / gethostbyname() loop to connect to one address
[where TCP retry timeout could not be warranted]

You'd be proposing to create a new function to accomplish 2) in such a
manner that it would also react to ICMP messages, etc?

Exactly.

Then, within that function, each individual connect() could react to ICMP messages a
as you proposed, but if all addresses fail because of ICMP errors, it could let TCP retry in the hope the transiet problem will dissappear.


[....] 
> Doesn't the problem really have to do with having applications performing
> such a low-level action?

At some point, someone has to decide which behaviour is desirable.
Isn't this only hiding the same policy decision inside an abstraction
layer

Yes, but even when the difference may sound subtle, IMHO it's not.
Having that abstraction layer is what let's you choose a policy, without having the risk of causing any harm to existing apps.
That way, if you ever need to change the low-level-connect() behavoir for whatever reason, you could still do it. As far as the high-level connect() behaves the same, there would be no problem.

Think about it. Why should an application programmer care about TCP retries, ICMP erros, an the like?
In the same way, why should he care about setting "strange" options such as SO_REUSEADDR on his listening socket?
Should *he* really handle byte-ordering issues by means of htons() and the like?


-- and the same could be achieved by e.g. a setsockopt() flag?

Strictly speaking, you *could* do that. But then you'd have all programmers implementing themselves a function you could provide them.
You'd have all them implementing the getaddrinfo()/gethostbyname() loop, setting a strange socket option, etc. Why not provide them with a well-tested function, and let them spend their time implementing their application itself?



(I don't deny that better APIs would not hurt, but we still seem to
require low-level C-like primitives, and unless there are additional
ones implemented there, we still have to fix the problems somehow..)

Well, the low-level ones could be provided as part of the new API.

Or along with the providing a new API, the current one could be modified as you suggest. It wouldn't hurt too much if the *low-level* API aborted a connection establishment because an ICMP error is received. Being a *low-level* API, you'd be suppossed to know the details behind the function.

Best Regards,


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org