From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-01-22 07:45:49
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
operations... I've read through the message archive and the posted
files (especially the requirements document at
http://groups.yahoo.com/group/boost/files/sockets2/Sock-req.html).
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:
boost::socket s("www.yahoo.com","www");
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?
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
ideas?
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?
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
programmers. Ideas?
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
regarding this.
Thanks,
Dave