On Wed, 11 Jan 2006, Hickman, Greg wrote:

I apologize if this ground has already been covered. I'm obviously late to the dicussion.

Only a little later than me :-)

...

really using. I don't see how one can get hold of the raw socket descriptor to twiddle options that the library hasn't abstracted.

Would a viable approach in this case be to provide platform-specific or "hidden" socket options as "optional" public interface according to whether those options are available on a given platform?

If you do that, you still get into the situation of having to replicate what is essentially a system interface at a level that is supposed to provide abstractions and a certain measure of system independence, right? I'm not sure that the Right Thing(TM) is to allow direct access to file descriptors or handles, but the fact remains that over the years I've come up with enough time that I've needed to access something platform or system-specific related to sockets that I've needed something like this. I don't think it makes sense for asio to become a kitchen sink for those sorts of things, but one also shouldn't be forced to break encapsulation or abandon asio because one needs functionality from one of the lower level tools that the asio designers/developers didn't anticipate.

On a related note, should a general-purpose socket library really couple socket classes to an event demultiplexer? Although Asio is more than a socket library, my first inclination would have been to build the socket abstractions independently of auxiliary concepts in such a way as to allow users to combine their usage in the manner most appropriate for their applications. And it does seem like that approach would lead to a socket handle accessor on the public interface of socket classes.

Much in the same way I wondered about putting thread and tss abstractions in asio, I wondered the same thing about sockets/handles, but wasn't sure (since I'm a boost newbie) whether there was an analog to boost.thread for sockets. Your comment is interesting, though, as this is one of the approaches I've seen and participated in that works and has stood the tests of time. -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2005 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<<