Re: about IPv6

 
Hi Ian -

[cc: vm-dev for the usual suspects]

Okay, after looking through the changes it seems like most of the
implementation should be fairly straightforward. There are a couple of
questions I have about various areas though:

* Concurrent lookups: It appears that the resolver can't be used
concurrently, is this right? (I had hoped we'd get rid of it in this
round) Also, it seems that the image side code isn't currently
serializing requests properly, in particular when getting the "next"
address information etc. Is this correct or am I missing something?

* "Local" addresses: What exactly does the "local" address family mean?
In your code you seem to simply stat() the input - are these files? If
they are files, why would one use sockets to access them (we have a
FilePlugin after all ;-) and what security implications does that have?

* Socket address lifetime: Why are socket addresses bound to the current
session? It seems to me that the client should be able to decide for how
long to cache an address. It's probably a good idea to dump addresses
when the system gets restarted but I don't see why this would be
*necessary*. And if it isn't necessary, I'd prefer to leave that option
to the client.

* Address families: Does it make sense to add AF_IRDA (infra-red) and
AF_BTM (bluetooth) as available address families? Windows supports them
but I don't know about the Unixes. And while we're at it: How about
SOCK_RDM (reliable datagram) and SOCK_SEQPACKET (pseudo-stream) sockets?
Croquet could sure use those if supported ;-)

Cheers,
   - Andreas

 
Hi Andreas,

> * Concurrent lookups: It appears that the resolver can't be used  
> concurrently, is this right?

AFAIK the underlying API is not re-entrant.  You'll have to serialise  
concurrent requests inside the image.

> (I had hoped we'd get rid of it in this round)

Calling it a 'round' is something of a grandiose overstatement.  It  
was a measured response to an immediate OLPC need, designed to be the  
smallest possible set of additions to get the job done without  
breaking anything.

> Also, it seems that the image side code isn't currently serializing  
> requests properly, in particular when getting the "next" address  
> information etc. Is this correct or am I missing something?

In the lightweight changeset that I sent you there was no attempt  
whatsoever to deal with serialisation; it was the minimum required  
just to test the API from a single thread.  The image code from Mike  
and Bert is where you should be looking for more reasonable behaviour.

> * "Local" addresses: What exactly does the "local" address family  
> mean?

UNIX domain sockets.

> In your code you seem to simply stat() the input - are these files?

They are sockets that appear as nodes in the filesystem.  They are  
used to make 'named pipes'.

> If they are files, why would one use sockets to access them (we  
> have a FilePlugin after all ;-)

Lightweight IPC: they give you the same LIFO behaviour (and API) of  
socket communication but without the overhead of an IP stack.  E.g.,  
when you open the display ':0' in X11 you are really opening a TCP  
connection to the UNIX domain socket called '/tmp/.X11-unix/X0' which  
(once opened) behaves like a network connection between two processes  
but with lower overheads (because the processes are running on the  
same physical machine with no link layer between them).

> and what security implications does that have?

I have absolutely no idea.  If you have read access to a UNIX socket  
then you can try to connect to it.  The listening process can  
obviously refuse the connection if it doesn't like you.

> * Socket address lifetime: Why are socket addresses bound to the  
> current session? It seems to me that the client should be able to  
> decide for how long to cache an address. It's probably a good idea  
> to dump addresses when the system gets restarted but I don't see  
> why this would be *necessary*. And if it isn't necessary, I'd  
> prefer to leave that option to the client.

Platforms do not agree on the representations of socket addresses.  
If you keep hold of a socket address that was generated on BSD and  
later pass it to a primitive running on Linux you will get unexpected  
results (at best the primitive will fail).  There are primitives to  
convert between the 'cached' socket address structures and numeric  
representations as strings, and the latter is what you should cache  
if you want to avoid the overheads of name resolution.  The validity  
has basically the same extent as the current primitives (session ID  
in private struct equal to the current global net session).

> * Address families: Does it make sense to add AF_IRDA (infra-red)  
> and AF_BTM (bluetooth) as available address families? Windows  
> supports them but I don't know about the Unixes. And while we're at  
> it: How about SOCK_RDM (reliable datagram) and SOCK_SEQPACKET  
> (pseudo-stream) sockets? Croquet could sure use those if supported ;-)

The new primitives were designed to support additional address  
families with (in general) just the addition of a constant to  
differentiate the new family from the others (modulo the ability of  
your particular getaddrinfo implementation to deal with symbolic  
representations of addresses within a given family).  Being able to  
communicate with that address once you've created it depends on  
entirely other things: the send/recv primitives understanding the  
protocol family, your kernel being configured with the required  
support, etc...

AFAIK IRDA is a serial protocol, so I'm unsure why it needs an  
address family of its own?  I don't know anything about Bluetooth  
(and prefer to keep it that way) although I expect addresses (if they  
even exist as such above the link layer) will be trivial.  FWIW,  
here's what a typical Unix knows about (although whether or not any  
given AF is supported depends on library and kernel capabilities,  
configuration, etc.):

AF_LOCAL (local to host: pipes)
AF_INET (IPv4)
AF_IMPLINK (arpanet imp addresses)
AF_PUP (pup protocols)
AF_CHAOS (MIT CHAOS protocols)
AF_NS (XEROX NS protocols)
AF_ISO (ISO protocols)
AF_ECMA (European computer manufacturers)
AF_DATAKIT (datakit protocols)
AF_CCITT (X.25, etc)
AF_SNA (IBM SNA)
AF_DECnet (DECnet)
AF_DLI (Direct data link interface)
AF_LAT (DEC Local Area Transport)
AF_HYLINK (NSC Hyperchannel)
AF_APPLETALK (Apple Talk)
AF_ROUTE (Internal Routing Protocol)
AF_LINK (Link layer interface)
AF_COIP (connection-oriented IP, aka ST II)
AF_CNT (Computer Network Technology)
AF_IPX (Novell Internet Protocol)
AF_SIP (Simple Internet Protocol)
AF_NDRV (Network Driver 'raw' access)
AF_ISDN (Integrated Services Digital Network)
AF_INET6 (IPv6)
AF_NATM (native ATM access)
AF_NETBIOS (NetBIOS)
AF_PPP (point-to-point protocol)
AF_ATM (ATM)
AF_NETGRAPH (Netgraph sockets)

Cheers,
Ian

 
On Aug 15, 2007, at 9:14 AM, Ian Piumarta wrote:

> Hi Andreas,
>
>> * Concurrent lookups: It appears that the resolver can't be used  
>> concurrently, is this right?
>
> AFAIK the underlying API is not re-entrant.  You'll have to  
> serialise concurrent requests inside the image.

Scratch that -- my brain was thinking 'concurrent' at the wrong level.

Yes, we could give back a handle on a particular address info result  
and use that to keep multiple concurrent retrievals from within the  
image happy; the client would have to explicitly destroy the handle  
when done to free up the result.  Since this was not the simplest  
thing that would make OLPC happy, I didn't do it.

Cheers,
Ian

 
Ian Piumarta wrote:
> In the lightweight changeset that I sent you there was no attempt
> whatsoever to deal with serialisation; it was the minimum required just
> to test the API from a single thread.  The image code from Mike and Bert
> is where you should be looking for more reasonable behaviour.

Sounds fine, thanks. Just making sure I understand the intended behavior.

>> * "Local" addresses: What exactly does the "local" address family mean?
[... snip ...]
> They are sockets that appear as nodes in the filesystem.  They are used
> to make 'named pipes'.

Okay, so nothing I need to worry about here.

Ah, interesting. I didn't know that but I had silently wondered why
getaddrinfo and friends would take numeric strings and have an extra
flag to tell it that they are numeric strings ;-)

I see. Are address families something that we consider platform
dependent features? Unix domain sockets, for example, will obviously
only supported on Unix. It should be fine if primSocketCreate fails for
an unsupported address family, right?

Cheers,
   - Andreas