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