Re: [boost] Boost Socket Library - Design Questions

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
 >operations...

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
 >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?

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
 >ideas?

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, 
supposedly.

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 
existence.

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 
it.

 >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
 >programmers.  Ideas?

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
 >regarding this.

Do you mean partial specialization?  A bit more specific example might be 
helpful.

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.

--Beman