From: gtpaw (gtpaw_at_[hidden])
Date: 2002-02-26 03:50:59
--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "gtpaw" <gtpaw_at_w...> wrote:
> > When implementing an interprocess communication (IPC) mechanism,
the
> > developer usually ends up with the same top-level design, no
matter
> what is the underlying
> > communication engine (sockets, shared memory, pipes, etc.).
> > Hence, IMHO, the socket library's functionality should be
> restricted to the following
> > primitive operations: connect, listen, send, recv.
>
> Yes, but what about connectionless protocols, like UDP? (accept()
and
> listen() are meaningless for these). Do we want to support them?
> Obviusly limiting the socket library to TCP only will simplify
> everything. Another issue is that availability of protocols can
> frequently be determined at runtime only (although TCP is probably
> always supported). Yesterday I was playing around with my own
socket
> library that supports UDP, only to discover that UDP isn't
installed
> on my machine (NT4.0). That makes me wonder if compile-time
protocol
> binding is a good idea.
>
I think this implies that - speaking from the IPC library's
standpoint - the 'logical protocol' is more significant than the
actual communication engine. One can even suggest that a UDP socket
and a TCP socket should be implemented by two distinct libraries (I
don't agree with that, though, because that means a great deal of
code needs to be duplicated).
I'm suggesting we first define several protocol-oriented interfaces
(TCP-like, UDP-like, etc.). Once we agree on these interfaces we can
implement them via whatever set of APIs we'd like.
Other than that, I believe that a socket library which supports every
possible socket feature, is very likely to be non-portable.
> >
> > Naturally, If we get the details right, we can also implement a
> > corresponding pipe library, and a shared memory library.
> >
> > At the next step, we can create an IPC library, which will use
> either
> > of the above-mentioned libraries. This library would support both
> blocking and non-blocking
> > I/O operations, thru an inserter/extractor interface:
> >
> >
> > typedef boost::ipc<boost::socket> my_ipc_t;
> > my_ipc_t my_ipc;
> > .
> > .
> > // writer1 uses a 1000 ms timeout period
> > my_ipc_t::writer_type writer1 = my_ipc.make_writer(1000);
>
> Doesn't this imply that a writer is copyable? I don't think it's a
> good idea.
>
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.
>
> [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.
-Itay