From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-22 15:09:52
At 07:45 AM 1/22/2002, dmoore99atwork wrote:
>I have some time off from work and would really like to post up a
>complete set of wrappers for address resolution and basic socket
It is really good to see someone rising to the challenge. We really need
this in both Boost and the C++ standard library. People often ask for it.
> I've read through the message archive and the posted
>files (especially the requirements document at
>In that terminology, I'm shooting for Layer 1. In comparison to
>other posted efforts, I'm trying to do a little bit more with
>wrappers for in_addr and sockaddr_in so that addressing/name
>resolution can occur in ways other than:
>I do have a couple of questions for other people who have spent time
>thinking on this problem...
>1. When resolving a symbolic internet address such
>as "www.yahoo.com", both "gethostbyname" and the
>newer "getaddressinfo" can return multiple IP addresses.
>Eventual socket connects *could* cycle through these addresses while
>connecting, but this might be unexpected behavior to the user. I'm
>leaning towards both a simple connect that takes an object wrapping
>sockaddr as an argument, plus a "connect_any" that takes a list of
>such addresses. Comments?
That sounds like a good plan, but I don't have enough experience to
know. Would anyone with actual sockets experience care to comment?
>2. Setting/Getting socket options has always seemed to be error
>prone to me, both in the fact that the argument data types differ
>from option to option, and in the fact that different options (i.e.
>linger) behave differently on different platforms.
>But, I can't think of anything that is an improvement. Even if we
>wrap the most common options with member functions - i.e.
>socket::nonblocking(bool flag), we would still have to provide an
>escape hatch for more esoteric or platform specific options. Any
At one time, all file I/O was believed to be innately platform
dependent. Options in particular were seen as something that could never
be unified into a single interface. It wasn't even worth trying,
Then along came the Unix and C library I/O functions (and Cobol too), with
only a few options, and yet the model they presented turned out to be
flexible enough to drive all the platform specific I/O schemes out of
So don't give up quite yet. Bill Kempf has a similar challenge with
Boost.Threads. Consider asking for help, both on Boost, and perhaps on
comp.protocols.tcp-ip.domains. Search the web, too.
Try to at least come to the point where having to specify platform
dependent options is really rare. Most tasks should be accomplished with
only platform independent options.
People will tell you that without platform specific options, performance
will suffer. Make them prove that with actual timings in realistic use
scenarios. Then remember that Moore's law still has plenty of life left in
>3. Exception design. Socket and name resolution functions can
>return quite a wide range of (platform-specific) error codes. I am
>leaning towards a small set of exception classes, rather than one
>type for each underlying error. Something
>like "addressing_error", "resource_error", "recoverable_socket_error",
> "nonrecoverable_socket_error" Comments?
Whenever this discussion comes up, it seems like it often starts out with a
bunch of possible exception classes. Then as the problem gets better
understood, and the anti-complexity folks get their shots in, the number of
exception classes gets reduced to a minimum. Why shortcut that by starting
out with one or two, then add others only if really, really, needed. (Also
see peer shutdown comments below.)
>3a. Peer shutdown. When a read() on a socket returns 0 bytes, this
>indicates that your socket peer has shutdown or closed the socket...
>Not checking for this is a classic socket programming error, which
>makes me lean towards throwing a "socket_closed" exception. BUT,
>this is analagous to an EOF condition for file I/O, which does not
>throw... We could conceivably invent an eof() return code for read()
>calls, but this would seem unnatural to experienced socket
I lean toward only throwing exceptions for true errors, not for something
expected like eof. But just yesterday I wrote a program where eof would
have been a true error, and so it was nice to turn on exceptions for the
stream, and forget about it.
What do others think about situations which lie somewhere in between
"always an error for sure, we really mean it" and "well, it is a bit
exceptional, but happens in every program sooner or later"?
>4. Basic template question: One of my first experimental designs
>was a templated "socket_address<>" class which I then explicitly
>specialized for IPv4 and IPv6. Can someone point me to a best-
>practices example *FOR CURRENT COMPILER TECHNOLOGY* for performing
>explicit specialization? I think I understand the standard rules ala
>Stroustrup, but had a hard time finding common ground between gcc and
>MSVC 6.0. I didn't see anything in the Boost programming guidelines
Do you mean partial specialization? A bit more specific example might be
Good luck with this! And thanks to the others who started the ball
rolling, but we just can't wait forever. Think about combining forces if
you are still interested.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk