Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt

[Fernando Gont <fernando@gont.com.ar>]

At 21:02 17/07/2004 -0700, Eddie Kohler wrote:

> > IMHO, requiring an application programmer more knowledge about networking 
> > and protocol specifics (soft and hard errors, etc.) is not a good idea.
> and:
> > He's still thinking about address-cycling being performed by the application.
>
> If the app cycles between addresses, then the app needs more knowledge 
> about networking than most currently do.

That's part of what I meant in my other post: Don't have applications do 
all these things, or they'll be working close to the network. Then whenever 
you want to change some protocol behaviour, it will likely affect the 
applications (which it shouldn't!).



> > Of course, if you provided application programmers with a higher-level 
> > API, all the soft errors and address cycling issues could be handled 
> > bellow the application.
> We agree!
>
> Here's my proposal.
>
> 1. "Kernel" socket APIs for TCP are extended with an option that allows 
> the app to specify whether "soft" errors should be treated as "hard".
>
> 2. A higher-level API is designed that handles multi-protocol DNS 
> resolution and address cycling, and that calls the "kernel" socket API as 
> appropriate to turn "soft" errors into "hard" ones during connection setup 
> (_iff_ there are multiple addresses to try).  In pseudocode:
>
>      open_socket_from_name(DNS_name) ::=
>          get list of addresses;
>          create socket;
>          if (more than one address) {
>              // Address cycling: first time through, treat soft errors as 
> hard,
>              // so cycling happens faster.
>              make soft errors hard on socket;
>              for (each address) {
>                  try connecting to current address;
>                  if (connect succeeded) {
>                      make soft errors soft on socket;
>                      return socket;
>                  }
>              make soft errors soft on socket;
>          }
>          // Second time through, treat soft errors as soft, to avoid failing.
>          // Alternately might cycle through addresses a number of times until
>          // some timeout occurs.
>          for (each address) {
>              try connecting to current address;
>              if (connect succeeded)
>                  return socket;
>          }
>          destroy socket;
>          return connection failure;

That's one of the ways it could be implemented. And I think indeed proposed 
this in March, when Pekka triggered discussion on this in the TCPM WG list.
(As a refinement, in case all connection attempts are aborted due to soft 
errors, the last for() loop could cycle several times, imposing an 
API-defined delay between each connection attempt).


> This type of structure seems like the right thing for many apps, but not all.

Are you thinking about any specific application?


> But there are a lot of potential parameters,

Correct. That's why I said "just because it's more abstract it doesn't mean 
it will be less powerful" in my previous post.


> and experience is required.  So you should only specify it in a library API.

Now, back to the current scenario: We have one problem, only one API, and 
do not want all existing apps to have to be modified.

The long term solution (which would probably avoid future posible problems) 
would be that of having applications use a High-Level API. But there has to 
be some work-around before there's such a High-Level API. The proposed 
solution tries to solve the problem without bothering application programmers.

Thanks for your comments!


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