Boost logo

Boost :

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.
> 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
> applications.

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
( I
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, gregod at, cpdaniel at, john at