Re: Sockets library requirements

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