Design rationale behind that separate acceptor class exists in ASIO

Question

I'm trying to understand why does ASIO have a dedicated

tcp::acceptor

class.

Under the hood, both

tcp::acceptor

and

tcp::socket

contain an

int socket_fd

, don't they?

Why not just add

tcp::acceptor

's unique functions into

tcp::socket

?

tcp::socket

can do anything which can be done by the low-level

int socket_fd

, except

listen

&

accept

.

(I am new to ASIO, maybe I don't see something fundamental)

Recommended for you: Get network issues from WhatsUp Gold. Not end users.

Answer 1

They have a separate set of operations.

Also, they have a separate set of socket options that apply, e.g.

acceptor_.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));

This distinction raises the abstraction of the interface and makes it easier to use the API correctly.

To put it bluntly, you could say it's because it's a C++ API, not BSD sockets.

It's the same answer you'd get when you'd have asked why socket was made an object with methods (instead of just passing the handle around, much simpler really?). Or why the classes are all templated on the protocol (remember casts like (struct sockaddr_in *) p->ai_addr? You'll see the merit).

Design rationale behind that separate acceptor class exists in ASIO

Sign up