[Vm-dev] Re: about IPv6

[Ian Piumarta]

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