AW: [boost] Re: Sockets library requirements

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
> 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
(http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html). 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.

Yep.

Boris