Re: getnameinfo and various protocol types

[Joshua Graessley <jgraessley@apple.com>]

On Dec 12, 2003, at 1:15 AM, Jun-ichiro itojun Hagino wrote:

> > > > 	now we have couple of new transport protocols coming, such as SCTP 
> > > > and
> > > > 	DCCP.  how can we support service name lookup for those?  i.e.
> > > > 	how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
> > > > 	argument of getservbyport(3)?
> > > > 	
> > > > 	my proposal:
> > > > 	define NI_UDP as replacement of NI_DGRAM.  deprecate NI_DGRAM (keep
> > > > 	it as an alias to NI_UDP is okay).  define NI_SCTP, NI_DCCP and 
> > > > such.
> > > > 	these three are mutually exclusive, and if more than one is 
> > > > specified
> > > > 	it would cause EAI_FAIL.
> > > Since getnameinfo in theory should apply to non-Inet protocols
> > > I think it would be useful to try to abstract from NI_SCTP and 
> > > NI_DCCP
> > > to something which captures the flavors/attributes of those 
> > > transports.
> > > I don't know if NI_SEQPACKET is descriptive for SCTP and protocols
> > > of that flavor.
> > > I have no idea what a more abstract name would be descriptive for 
> > > DCCP.
> > 	SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
> > 	DCCP should be SOCK_DGRAM only, if i understand correctly.
> >
> > 	therefore, there's no 1-by-1 mapping from SOCK_xx to IPPROTO_xx.
> 	to clarify, i agree there should be some way to support non-inet
> 	protocols, however i'm not sure how service lookup works for non-inet
> 	protocols.  do people have any examples (such as appletalk or 
> whatever)?
AppleTalk is dead. Well, it's not quite dead yet, but it's getting 
there.

AppleTalk used something called NBP (Name Binding Protocol?). There 
were no host names, only service names. Services were discovered by 
type and a service name (an instance of a service) was resolved to an 
AppleTalk address and port. AppleTalk didn't have the notion of 
different sets of port lists for different protocols. The port came 
right after the address. It would be sort of like layering TCP, ICMP, 
and all other IP protocols on top of UDP.

It is unlikely anyone would ever work to support AppleTalk service name 
resolution through the getnameinfo API.

I don't think it is useful to abstract NI_SCTP and friends to support 
non-inet protocols. No matter what you do with getnameinfo, writing 
code to try and abstract out the protocol family with the socket APIs 
is nearly impossible. If someone wants to support some non-inet 
protocol, then they can probably handle an additional lookup or use 
some new vendor specific value that means SCTP or 
ApplesSCTPLikeAppleTalkBasedProtocol. What is there other than IP/IPv6? 
NetBIOS...IPX...AppleTalk...OSI? They're all dying (or should be).

-josh

Attachment: smime.p7s
Description: application/pkcs7-signature