From: jelco78 (marcojez_at_[hidden])
Date: 2002-02-24 06:44:49
--- 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
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).
Marco