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