Re: Sockets library requirements

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