Boost Socket Library - Design Questions

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