Extends TcpNetworkSocket adding support for TLS
Assemblies: EchoSCU (in EchoSCU.exe) Version: DCF34 r12431 DCF_3_4_38_20200923 NetFramework
VerificationSCPExtended (in VerificationSCPExtended.exe) Version: DCF34 r12431 DCF_3_4_38_20200923 NetFramework
public class TlsNetworkSocket : TcpNetworkSocket
Thetype exposes the following members.
Allow client to not send a certificate
Allow self-signed certificates
TLS authentication timeout in msecs
The TLS certificate.
Which TLS protocols are enabled: 1.0, 1.1, 1.2
Ignore certificate name mismatch errors
True requires client to send a certificate
Get the active TLS protocol from the TLS connection stream
Write to socket timeout in msecs
Overridden server-side accept of an incoming connect request.(Overrides .)
Close the socket(Overrides .)
Close the socket with a timeout in seconds(Overrides .)
Connect the socket to the given TCP endpoint(Overrides .)
Connect the socket to the given IP address and port(Overrides .)
Connect the socket to the given host and port(Overrides .)
This method should be called to authenticate the TLS stream as a client.
This method should be called to authenticate the TLS stream as a server. For a server side TlsNetworkSocket, when LAZY_SERVER_SIDE_AUTHENTICATION_MODE is false, this method is called when DCF's AssociationManager.run() calls waitForServerConnection() which then calls this instance's Accept() method. In this situation, the AssociationManager will not accept more connections until this method has completed. This method may not complete quickly, for example, if the client side does not send authentication information such as a TLS Client Hello message, which will happen if a non-TLS client connects to the SCP's TLS port. Such a situation can lead to unacceptable delays (waiting for a timeout) in accepting future associations. For a server, when LAZY_SERVER_SIDE_AUTHENTICATION_MODE is true, this method is called by AssociationManager.HandleAssociation() in a new thread, after waitForServerConnection() has completed calling Accept(). Therefore, future connections are not blocked waiting for this method to complete. Note that a consequence of handling the authentication in this manner is that the DCF AssociationManager has incremented its association count to handle this in a new thread. In case of a bad connection request, that association counter will not be decremented until a timeout or other error completes the thread's operation.
Enter the listen state with the backlog queue length(Overrides .)
Invoke a poll on the socket with microseconds timeout and selected mode(Overrides .)
Read data from the socket into the buffer at offset limited to count bytes(Overrides .)
Write the buffer data to the connected socket(Overrides .)
|Send(Byte, Int32, Int32)|
Write the buffer data to the connected socket starting at offset bytes and limited to count bytes(Overrides .)
Whether to allow wildcard and SAN (multi-domain) certificates
Whether to call AuthenticateAsServer() immediately or wait until we attempt to send or receive from a server side socket connection; effectively, this equates to whether to authenticate on the main listen socket itself or on a child socket that was created by a call to Accept(). NOTE also that when this is set to "true", AuthenticateAsServer() is called only when the underlying .NET code calls one of this class's overridden Receive() or Send() methods --which is indeed happening currently, after Accept() has been called, when the DCF attempts to read the first PDU of an association in a newly created thread.