AF_VSOCK connection refused errno

When connect(2) fails because the peer is not listening the virtio vsock
transport returns ECONNRESET.  I believe the VMCI transport does the
same (based on code inspection).

Jorgen: Can you confirm this VMCI transport behavior?

I'd like to change to ECONNREFUSED for all transports because developers
will be surprised when they get ECONNRESET.  It makes porting AF_INET
code harder.

On the other hand, it may be too late to fix this if there userspace
applications that rely on ECONNRESET?  I'm not aware of any such
applications myself.

Thanks,
Stefan

On Dec 12, 2017, at 4:53 PM, Stefan Hajnoczi [off-list ref] wrote:

When connect(2) fails because the peer is not listening the virtio vsock
transport returns ECONNRESET.  I believe the VMCI transport does the
same (based on code inspection).

Jorgen: Can you confirm this VMCI transport behavior?

Yes, that is correct.

I'd like to change to ECONNREFUSED for all transports because developers
will be surprised when they get ECONNRESET.  It makes porting AF_INET
code harder.

On the other hand, it may be too late to fix this if there userspace
applications that rely on ECONNRESET?  I'm not aware of any such
applications myself.

In the past, I’ve explained to customers that an ECONNRESET error on connect
can indicate that the peer isn’t listening on the dest address. Whether they went
and used that information isn’t clear, but changing this behavior now would
risk breaking applications. While it is unfortunate that we deviate from INET in
this case, I would prefer it to stay as is.

Thanks,
Jorgen

On Wed, Dec 13, 2017 at 10:28:30AM +0000, Jorgen S. Hansen wrote:

quoted

On Dec 12, 2017, at 4:53 PM, Stefan Hajnoczi [off-list ref] wrote:

When connect(2) fails because the peer is not listening the virtio vsock
transport returns ECONNRESET.  I believe the VMCI transport does the
same (based on code inspection).

Jorgen: Can you confirm this VMCI transport behavior?

Yes, that is correct.

quoted

I'd like to change to ECONNREFUSED for all transports because developers
will be surprised when they get ECONNRESET.  It makes porting AF_INET
code harder.

On the other hand, it may be too late to fix this if there userspace
applications that rely on ECONNRESET?  I'm not aware of any such
applications myself.

In the past, I’ve explained to customers that an ECONNRESET error on connect
can indicate that the peer isn’t listening on the dest address. Whether they went
and used that information isn’t clear, but changing this behavior now would
risk breaking applications. While it is unfortunate that we deviate from INET in
this case, I would prefer it to stay as is.

That's fine.  Thanks for confirming.

Stefan