Re: [boost] Re: Sockets library requirements

From: Vladimir Ciobanu (psycho_at_[hidden])
Date: 2002-02-24 18:52:49

Hi

----- Original Message -----
From: "jelco78" <marcojez_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, February 24, 2002 1:44 PM
Subject: [boost] Re: Sockets library requirements

> --- In boost_at_y..., Boris Schäling <boris_at_h...> wrote:
>
> [...cut...]
>
> > If you like to send me your socket library I'll have a look at it.
>
> I'd like to, but I lost the original code (I know, ALWAYS make
> backups...). I could rewrite it, but as someone replied, there are
> already other socket libs in the air to be submitted to Boost, so
> I'm not going to do any useless work. Anyway, just for information,
> my library was structured more or less this way:
>
> 1) A <netaddress> unit which contains two classes: Ip_address and
> Socket_address. Here's a brief description:
>
> + Ip_address holds (of course) an IP address, version 4 only; it

    I think at some point IPv6 should be implemented, too.

> provides conversions to and from character strings for dotted
> representation, using system functions like inet_addr() in its
> implementation; two special Ip_address objects are automatically
> created: invalid_ip, which identifies an invalid IP address, and
> broadcast_ip, for broadcast sends.
>
> + Socket_address acts like a container for an Ip_address and a
> Port_type (Port_type is a 16 bit integer); it allow conversion
> to/from character strings in the form "a.b.c.d:port" and access to
> both the stored IP address and port number.
>
> 2) A <socks> unit which contains the class Socket. This is a very
> minimalist socket representation, designed for ease of use rather
> than high control over socket features. An instance of the Socket
> class is a noncopiable object that holds a socket descriptor and
> socket state, using the Pimpl idiom to hide implementation details
> (and to avoid including system headers in socks.hpp). Since I wanted
> to keep this lib portable across platforms, I decided to drop
> support for non-blocking sockets, because this feature is not
> directly related to networking standards, and is not guaranteed to
> be supported on other platforms/systems. Optionally, one could
> decide to provide an intermediate layer to interface the Socket
> class with some Boost.Thread classes in order to get a non-blocking
> effect in a much more portable way.
> The socket object in my lib is simple, it has only four states:
> Idle, Connecting, Connected, Disconnecting, Listening. The first
> state (Idle) is the default one. The Connected and Listening states
> are the result of calls to connect() and listen() member functions.
> A call to disconnect() make the state fall back to Idle.
> If anyone of these functions fail, the state will fall back to Idle
> and an exception will be thrown.
> Any intermediate operations, like address bindings, are totally
> unknown to the final user and are not directly accessible. They are
> issued internally by the other member functions, and any failure in
> these operations result in a failure of the whole function.
> As I said before, this is a minimalist design; so, there is no
> interface change between stream-oriented and message-oriented
> sockets. Instead, a message-oriented socket behaves just like a
> stream-oriented one: a connect("147.123.1.2:21") on a message-
> oriented socket will redirect all messages sent with the send()
> function to 147.123.1.2:21, while a disconnect() will remove this
> binding.
>
> Error reporting was made possible using several exception classes.
> Of course I didn't write a single exception class for each system-
> defined error (it would be simply useless); instead, I created few
> exception classes which *optionally* carries a system-defined error
> code that an exception handler could decide to display.
>
> My lib provided also an higher-level layer for streaming. A simple
> derivation of the basic_streambuf<> template makes possible to use
> standard stream functions across sockets (just like file streams).

    I've talked about this with serveral people and they pointed out that
it doesn't make sense to derive a socket from any standard stream. The
reason is that there are some functions which simply don't make sense
for a socket stream. Example:

seek*( )

    I'm sure they are other examples; this is the only one that I can think
of right now. I don't find C++ streams as the best way to represent
socket streams. I'd be happy with send/recv.

PS: lexical_cast can save us from implementing .toStr( ) on the types
we want to send as strings without the nice overloading operator<<
and operator>>.

Vlad