From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-02-26 06:02:30
> >
> I'm not sure about that, although I didn't give it much thought
yet.
> Alternatively, we can implement the boost::ipc class as a stream ,
> and use a stream manipulator to set the current timeout period.
I think what alot of people are saying here (including the Boost
Sockets Library Requirements doc in the Files section) is that you
can first build a simple lower layer with your 4 primitives: connect
(), accept(), send(), recv(), etc., and then implement iostream
functionality in terms of this lower layer.
The stream functionality will be a powerful thing for some people,
and a burden for others. We should not force it on anyone. However,
I'm starting to think that the first complete Boost socket lib to be
posted here should include the lower layer and the streams layer so
as to not be considered "incomplete"
As for timeouts, you can certainly implement them portably in a lower
layer for sockets with some combination of nonblocking i/o and select
() type functionality. You can then expose the timeout via a
manipulator to the streams layer, but you still need to implement it
fundamentally on your four primitives.
> > [cut]
> >
> > It's also unclear what socket streams would look like. How do the
> > two connected sockets coordinate byte ordering, locales, etc.?
> >
> If both the sending and receiving sides are boost::ipc objects then
> there shouldn't be much problem. In case I didn't make myself clear
> (which is very likely), I'm thinking of creating two flavours of
the
> IPC class: ipc_client and ipc_server. The above sample refers to an
> ipc_client.
Yes, but once a socket (or any other full_duplex IPC mechanism) is
connected, then it really doesn't matter who the client and who the
server is. That is one of the strong motivations for the
acceptor/connector patterns http://www.cs.wustl.edu/~schmidt/ACE-
papers.html that are mentioned here.
The alternative is to have ipc_server derive from ipc_client and add
the listen/accept calls to the basic interface. At least that way
you can share the implementation of send/recv.
Regards,
Dave