[boost] Re: (Another) socket streams library

From: pedro.lamarao_at_[hidden]
Date: 2005-04-21 17:10:25

Boris wrote:

[SNIP]

> - Why is your socket streams library better than other socket streams 
> libraries? (I ask to understand better the design and goals of your 
> library.)

Well, I haven't thought about that, really -- this is much more of a
research project to me. I posted the link seeing that the networking
discussion in this list is endless, and my project escaped attention.

What I am trying to achieve with this project is "easy semantics"; there
are a number of normal socket operations that, by the nature of the C
interface, end up being just boring.

Like the constant (sockaddr*) casting.

A "socket" class seems natural, being that the interface is typical:
resource descriptor, operations on resource.

And the "stream" classes provide a means for "protocol message" classes
to offer easy semantics to the natural "serialization" and
"desserialization" operations from a network "source".

I don't know why, or if, my project is better than anyone's, really, but
I'm seeing everyone trying to solve the big problem, not the small ones.

> - Do your socket streams support blocking and non-blocking I/O?

Not yet, I believe; although I haven't experimented with that much.

I'm still undecided if it's best to choose some int_type value to become
"would block" like there's eof() or if it would be best to have a
would_block() method in the stream classes.

That's really one of the next things in my list, now that "resolver
result container" has some form.

> - Is it possible to use your socket streams without them throwing 
> exceptions? (I ask as I see a class socketstream::exception.)

Yes. Exceptions are thrown by the "basic socket" class, instead of
returning (-1). socket_exception tries to ease the errno checking.

> - As far as I can see your socket streams are not limited to stream 
> sockets - you can use datagram or even raw sockets? I haven't thought about 
> this yet but I am not sure if the interface of I/O streams makes sense for 
> datagram and raw sockets?

Not yet, I think. I'm still thinking about what a "datagram stream"
would mean... My best thought has been for something like a "datagram"
class offering operator>> and operator<< together with sendmsg and
recvmsg... But I don't really know.

The code in Sourceforge is usually not the latest one; I prefer to
develop here: https://mndfck.org/svn/socketstream/

There's some new stuff there I really like, specially the "resolver
result container" thing. Please take a look and tell me what you think.

There's also new examples for echo, chargen, discard, time, quote, and
daytime "protocol servers". I'm soon to write an example IRC server, but
that'll probably take a while -- I'm still to graduate. :-D

--
 Pedro Lamarão