[boost] Re: Networking library

From: Michel André (michel.andre_at_[hidden])
Date: 2003-11-10 14:15:41

Hi!

> Yes, there was, and yes I removed it, or rather moved it into the
> socket acceptor, connector and connection classes.  My rationale for
> this was essentially
>     i) to have a single level in the implementation of the basic socket
>        class. The requirement to not include system headers implies a
>        non-templated implmentation.  An error policy implies templates,
>        so requiring a second level.
>    ii) the generation of platform indepenedent error codes was a
>        requirement.  This , as in i), implies that an error policy
>        needs to be in a level above the basic wrapping.
>   iii) I didn't want the complication of converting socket types
>        that differed only in there error policies.
>    iv) The error policy presumably depends on what use you are making of
>        the sockets

Ok this sounds fair enough. With the new asynch like model is error policy
needed shouldnt there be an socket_errno sent with each notification or an
on_error notification that can be hooked on the connection class?

> Yes, documentation definitely required.  However, I would be very
> interested in just having feedback as to whether mapping all the
> underlying demultiplexing variants to a proactor type
> user interface is something people are happy with.  Personally, having
> a single interface for the user to code to is useful, relegating
> blocking/non-blocking/asynch and select/poll/completion-port
> choices to be (configurable) implementation details as far the user
> is concerned.

I really like the unified interface. But then my thinking is asynchrounus
from the outset and almost always implement network comms asynchrounously.
Maybe everyone isn't to excited about that model for simple clients with a
typical pattern of blocking connect/send request/recive reply/disconnect
cycle. But it would be easy enough implementing that using lower layer
constructs.

How is errors communicated to the on_read/on_write handlers communicated,
via the policy?

> > But now I need a C++ project not to get rusty as my daytime work is
> > almost completely .NET and C# :(
>
> How a about a .Net implementation in managed C++ then (joking, I
think...).
> I haven't seen any discussion here as to whether boost is interested
> in running in the managed world, and not having done much yet in .net,
> I don't know what is feasable.

I don't think so, and I'm not even interested in suggesting it ;). I look on
.NET as my daytime job and C++ as my nighttime job ;).

Regards
/M