2

I am trying to understand the concept of network programming using sockets.

As I understand there is a parallelity to a phone conversation, the

  • Endpoint would be the phone number, the
  • Socket the phone and the
  • Acceptor is the one picking up the phone.

So then, the

  • Socket is bound to the endpoint (the phone is connected to the plug) and the

  • Acceptor gets access to the socket and a handler (a person is put next to the phone and gets a task what to do if someone calls)

If that is a valid visualization, then why can you bind the acceptor directly to an endpoint and give the acceptor the socket afterwards? Or is the above plainly wrong?

tcp::endpoint ep(boost::asio::ip::address::from_string("192.168.XXX.XXX"), portNumber);
tcp::acceptor a(io_service);
tcp::socket s(io_service);

a.open(ep.protocoll());
a.bind(endpoint);
a.listen(boost::asio::socket_base::max_connections);
a.async_accept(s, myHandler);
default
  • 11,485
  • 9
  • 66
  • 102
MrJonas
  • 197
  • 11
  • well, you call the number before it connects you, right? So, to me, it seems appropriate to give the acceptor an endpoint before trying to connect with a socket. Why does it matter if they are comparable or not? Are you having any actual issues with using asio? – default Nov 23 '17 at 15:26
  • i was using `s.bind()` and then `a.async_accept(s, myHandler)` and it throws some `boost::exception_detail::clone_impl >` So, i thought, maybe my understanding of the matter is wrong. And I don't get the difference between socket and acceptor – MrJonas Nov 23 '17 at 15:35
  • 2
    The acceptor is binding to the local address. It's like, consider you have multiple phones. You tell the acceptor: listen on this phone but ignore the rest. So when the connection comes, the acceptor decides "yeah, the call is for my dev" and then it creates a socket so that you (the dev) can work with it. Does it help? – freakish Nov 23 '17 at 15:37
  • I think you would be better off explaining how you are using asio and what errors you get (in the question itself) instead of trying to force a comparison to some other physical object. – default Nov 23 '17 at 15:50
  • Thanks for the advice, but that is basically what I was doing continuously. I now hoped to get an intuitive understanding so that I can fix problems by thinking instead of googling every single step I want to take. (And actually lern sth.) – MrJonas Nov 23 '17 at 16:00

2 Answers2

1

Your equivalence is not accurate enough. Think of an acceptor as a sort of passive socket: it just waits for the other endpoint's socket to request for a connection, it is read-only. When the acceptor "reads" an request (i.e. when the corresponding I/O event triggered), it will branch off a new socket that is connected to the remote endpoint and delegates all further I/O work to it. The acceptor itself however stays in its passive mode.

Jodocus
  • 7,493
  • 1
  • 29
  • 45
  • so the acceptor is more like the phone that activates the the socket (the active person that can do stuff) when it gets a request (is called) and the socket is the active part which then uses the handler to know what it has to do. Is that better? – MrJonas Nov 23 '17 at 15:41
  • 1
    You may think of the acceptor as a secretary's phone waiting for inbound calls. If someone calls the secretary' phone, he/she will forward the call to the CEO's telephone. The boss may then do the conversation, hang up or call back. The secretary however never actively calls. – Jodocus Nov 23 '17 at 16:11
0

I feel your pain. I'm not a fan of the abstractions or api used in the boost::asio framework. Here's where I'm at with it at the moment.

An endpoint is a ip address and a port.

A socket is an abstraction on the concept of a channel in the engineering sense of the word. It's like a wire between two telephones, or the air between two antenna. It's defined by two endpoints the sender and the receiver.

An acceptor is a thing that sets up sockets (channels). A better name might be listener, though i would prefer a name that does not end in -er. Please advise if you can think of a good candidate. I found this post while looking for a better name to describe acceptor. Maybe a "receiver" would be a good name as it is an abstraction from a class of physical things. Example a satellite dish can act as a receiver.

Since you're in the land of boost::asio you might find it better to think of an io_service as an eventLoop. That one bothers me too.

You might find it valuable to look into the idea of invalid concepts from Objectivism (a school of philosophy) there seems to be a correspondence there between the challenges naming things and epistemology (the principles of knowledge).

aaronium112
  • 2,992
  • 4
  • 35
  • 50