From: Boris Schäling (boris_at_[hidden])
Date: 2002-02-24 06:37:50
> -----Ursprüngliche Nachricht-----
> Von: craigp98072 [mailto:craigp98072_at_[hidden]]
> Gesendet: Sonntag, 24. Februar 2002 05:46
> An: boost_at_[hidden]
> Betreff: [boost] Re: Sockets library requirements
> If you haven't seen ACE yet, I suggest you take a look.
> http://www.cs.wustl.edu/~schmidt/ACE.html. They have some very good
> design patterns for concurrent network programming. Even in terms of
> a minimalist design, I think they have a lot to contribute.
> I like the idea (from ACE) of separating the acception/connection
> strategies from socket streams. A passive accept_socket will return
> a socket_stream when it has accepted a connection, and active
> connect_socket will also return a socket_stream when it successfully
> connects. Only socket_streams can send and recieve data, and they
> behave the same regardless of how they were connected.
> A library which doesn't handle non-blocking sockets and timeouts is
> practically useless (IMHO) - except for the most trivial of
I agree. A design like ACE is much easier to use for someone who doesn't
have a clue about networking. Users expect that functions return
immediately - they have to use threads or fork just to support multiple
clients. That stuff is handled by a multiplexing library automatically so
the library doesn't force the user anything.
Basically you create a client or server object, register this with a
multiplexing object and pass an observer object which is notified by the
multiplexer object when the client or server received new data. It follows
the observer design pattern
have created such a library therefore I like this idea most. ;)
> It should be relatively easy to plug-in and/or layer additional
> protocols, such as SSL over TCP/IP.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk