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