On Tue, 2004-06-29 at 15:07, Brian E Carpenter wrote:
> Erik Nordmark wrote:
> >>On 28-jun-04, at 14:45, Erik Nordmark wrote:
> >>
> >>
> >>>And if the long-lived ID is one of the locators we can provide
> >>>compatbility
> >>>for unmodified applications which do referrals and callbacks.
> >>
> >>We should really talk to some apps people to figure out how important
> >>this is. It's entirely trivial to shoot yourself in the foot today with
> >>NAT or multiple addresses anyway, and then there is dual stack. How are
> >>referrals going to work when a future participant in the communication
> >>may be limited to one IP version, which happens to be the other one
> >>than the one used by current participants?
> >>
> >>It may very well be that apps and protocols need to be changed anyway
> >>in order to work with IPv6, or IPv4+IPv6.
getaddrinfo() doesn't require much changes on the network code front.
The user interface though tends to break when it forces a certain format
or restricts input. Developers should stick to accepting at least
hostname or actually any characters in [a-zA-Z\:\-\.], the problem here
is though that for IPv6 suddenly if you want to parse a URI and allow
IPv6 addresses to be specified you need to know about the [] semantics.
The trick IMHO is to never allow IP addresses to be used basically.
But there are many arguments against this eg 'how do I setup my
home-gateway which comes pre-installed as 2001:db8::1, that thing is
going to run DNS and I need to connect using HTTP'. Simple solution:
/etc/hosts but still ;)
> > My experience, and I think Kurt said something similar, is that it
> > is hard to engage application folks without something concrete like
> > a proposal that they look at. This makes it tricky to get feedback before
> > we have nailed down enough of the approach to be able write down how it
> > will affect applications, unless we do the work to present the apps folks
> > with a menu having different choices.
>
> What they see is an API and its explicit and implied semantics. So not only
> do we need to resolve the endless debate about the nature of an id, we also
> have to figure out how that will be represented in socket semantics.
>
> From painful experience, it is not easy to persuade middleware designers
> to change anything in the way they use sockets.
Even pursuading folks to start using getaddrinfo() doesn't work that
easily and most of them have a point.
A network application developer actually only wants this:
8<---------
char uri[] = "tcp://hostname:service";
sock = uriconnect(uri);
-------->8
A function similar like that should be abstracted by the networking
API's. getaddrinfo() requires a loop, weird cases etc, which you have to
duplicate in every application. The above would simply work(tm) and
doesn't require the application developer to worry about anything
networkish. The socket now presented by the API is for the application
the identifier and the only thing the API (or most probably the kernel)
would now have to do is make bloody sure that it keeps working, even if
it has to change underlying addresses etc. uriconnect() can abstract all
of that, the socket(), getaddrinfo() loop and the connect() call.
The identifier 'tcp://hostname:service' in this case will stay the same
and can be passed across most if not any boundaries (of course not
taking the assumption that somebody uses dns paths...) to other
applications in other networks etc.
Another option to look at is adding a function getidentifier(sock)*,
which returns a globally unique (we did have an globally unique IP
address hmmm... :) identifier, which then can be passed around.
The later is IMHO not a nice option as that would require changing many
applications (for IPv6 support they will have to change too so it is
kind of a moot argument), though it could be used. The getidentifier()
could btw return 'tcp://fdqn:service' making sure the above problem with
dns-path searches disappears.
I could then still do: sock = uriconnect("tcp://purgatory:http"); to
contact the http service on purgatory.unfix.org, as my search path
includes 'unfix.org', while when I want to pass it, I would do:
fprintf(sock, "I am looking at: %s", getidentifier(sock));
or a similar construction, which would throw:
"I am looking at: tcp://purgatory.unfix.org:http"
Server side can do the same:
sock = uriaccept("tcp://:http");
printf("The one who connected is %s\n", getidentity(sock));
Thus passing URL-like identities in applications seem to be the trick
IMHO, an application developer should not have to care about anything
else. Of course the other side app should then also know about HTTP etc
Long story short:
Maybe it would be an idea to create a draft which includes the
examples I mentioned above and start hinting developers to start
using those functions?
Greets,
Jeroen
* = of course:
char *getidentifier(int socket, char *buffer, unsigned int buflen);
to make sure that it also works with multithreaded apps...
PS: Including the protocol (tcp/udp) won't work easily for server side
stuff... especially with udp not really having an accept.
PS2: I usually tend to abstract the socket/getaddrinfo/connect into
a function like the one mentioned above and that works perfectly well.
PS3: 'High-performance' networking API's like those on Windows have a
completely different strategy of doing things thus fitting those into
the above model will be problematic too...
Attachment:
signature.asc
Description: This is a digitally signed message part