Re: Sockets library requirements

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