[Vm-dev] Re: about IPv6

[Andreas Raab]

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.

>> * 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).

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 ;-)

>> * 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...

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