Re: sockets /network programming Requirements

From: Joseph Berrios (jsberrios_at_[hidden])
Date: 2001-08-01 07:58:12

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 10:19 AM 7/31/2001, Iain.Hanson_at_u... wrote:
> 
>  >     Protocol.
>  >
>  >     The requirements currently say that the library should be (
>  >     predominantly ) restricted to IPv4 & IPv6. I would expect 
the 
> initail
>  >     implementation to be based on IPv4 as the is the most used 
of 
> network
>  >     protocols. However, it would be a mistake IMO, to not take 
other 
> main
>  >     stream but less popular protocols into account, for the 
requirements 
> 
>  >     and design. C++ and its libraries have, as far as I can see, 
always
>  >     attempted to be inclusive rather than exclusive. Excluding 
other
>  >     protocols from consideration in the requirements and design 
is 
> likely
>  >     to be detremental to the generality of such a design and is 
some 
> what
>  >     akin to saying we'll exclude the requirements for real-time 
systems
>  >     because thay are not main stream.
>  >
>  >     Protocols that I believe should *at least* be considered in 
the 
> design
>  >
>  >     are: OSI, SS7, and ATM. If anyone has any additions to this 
list, 
> I'd
>  >     be interested to here them.
> 
> Please consider the requirements a "straw man" meant to start 
> discussion.  Thus if you have experience that says they should be 
changed, 
> by all means do so.
> 
> I was trying to avoid expanding the requirements to include areas 
outside 
> of "network programming".  The sockets interface could be viewed as 
a 
> general read/write interface, and so feature creep might expand the 
library 
> way outside of the network programming arena.  Personally, I don't 
think 
> that would be a good idea, particularly for version 1.  But if it 
can be 
> expanded to handle other network protocols, without distorting the 
design 
> otherwise, that would seem to be a clear win.
> 
> --Beman

I beleive that for the implementation of the protocol, the best 
approach is to use a parent class with virtual functions (or with 
a similar more efficient mechanism).  With version 1 provide the 
interface for IPV4 and IPV6.  By having this parent class, it will 
make it easier to implement other protocols.  It is my beleif that 
the socket class needs to be a tool that can be built upon and this 
is a one example of room for growth that is needed.

Joseph