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