Re: [Boost-users] Enhancing the boost::asio::connect() socket interface

On Sun, Sep 24, 2017 at 1:15 AM, martin doc via Boost-users wrote: As boost::asio::connect() closes an open socket passed to it before making the remote connection, it's not possible to pass connect() a prebaked socket.

What makes you think that? My reading of the implementation is that the socket is only closed when: 1. The range of addresses passed to connect() has more than one element, and 2. The connection attempt for the first address fails. See: <https://github.com/boostorg/asio/blob/b002097359f246b7b1478775251dfb153ab3ff... You can avoid the socket closure by only attempting to connect to one address.

In fact the amount of code required to use boost when binding a socket to a local address is more complicated than simply not using boost.

That ignores all of the other benefits that Boost.Asio brings to the table once the connection is made. And what happens when the Networking-TS is merged into the standard? Will you just avoid using the standard library? Thanks On Sun, Sep 24, 2017 at 1:15 AM, martin doc via Boost-users wrote:

(apologies if this should be on -developers...)

The connect() interface provided by boost caters to most common use and through access to the socket, various options can be managed without much hindrance. But there's one situation that boost does not handle well - when it is desirable to specify the local address to bind to.

Going back to C, the usual program flow in this situation is something like this:

fd = socket()

bind(fd, local ip address)

connect(fd, remote ip address)

As boost::asio::connect() closes an open socket passed to it before making the remote connection, it's not possible to pass connect() a prebaked socket. In fact the amount of code required to use boost when binding a socket to a local address is more complicated than simply not using boost.

What I'd like the boost community to consider is extending boost::asio to provide one or more variants of connect() that allows for a local endpoint (whether or not as an iterator I'll leave to others to debate but this isn't necessary - and then there's the M*N behavior or paired to decide) to be supplied in addition to the remote endpoint.

I suppose I'm open minded as to whether or not the local address is supplied as an Iterator/endpoint as an extra arg or whether connect() is adopted to take endpoint pairs.

Thoughts?

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Follow me on GitHub: https://github.com/vinniefalco