[Info-vax] Device locked by non existing process.

[Arne Vajhøj]

On 5/4/2018 12:06 PM, Stephen Hoffman wrote:
> On 2018-05-04 01:38:00 +0000, Arne Vajhj said:
>> On 4/23/2018 6:32 PM, seasoned_geek wrote:
>>> Yes, IPv6 probably "should" be a default, but on at least one recent 
>>> program I did it with IPv4 because it wasn't worth swimming through 
>>> the septic tank to make IPv6 work. There was a legitimate reason, but 
>>> I would have to look at the code to remember.
>> Good socket code work with both IPv4 and IPv6 without changes.
> 
> Ayup.  That works fine across IPv4 and IPv6.

Which was my point.

>                                              TLS and DTLS above that 
> gets gnarly, in terms of the complexity of the APIs and the sorts of 
> examples available, and given the problematic implementation of TLS and 
> certificates on OpenVMS.

[speaking only about TLS as I have never looked into DTLS]

I think it somewhat depends on the language.

Java is relative OK as javax.net.ssl.SSLSocket extends
java.net.Socket, so you can just give whatever code that
expects a Socket a SslSocket and it will work.

And if a good DI framework is used then setting it all up
becomes configuration not code.

.NET is doing something similar just at a different place
as System.Net.Security.SslStream and System.Net.Sockets.NetworkStream
both extends System.IO.Stream. Of course .NET is not available for VMS.

C has a problem as standard socket API and OpenSSL SSL functions are
all different.

OpenSSL does have a go forward solution as BIO functions provide an
abstraction for both plain sockets and SSL sockets, but no old code
will be using that.

And I do not even want to think about how Pascal/Basic/Fortran/Cobol
would do SSL via SYS$QIO(W).

Arne