• DG is a proprietary RPC protocol implemented over TCP transport protocol. Each client connection “session” is a persistent TCP connection between the server’s configured TCP port (default, 5042) and a port assigned by the client system at connection initiation. Transport mechanics of DG sessions are very similar to TELNET protocol-based console connections to IBM i and other console platforms.
• DG servers are “passive listeners”; sessions can only be initiated by the client. When a client successfully opens a DG connection, the connection remains open until the client actively closes the connection, or a server/network exception occurs.
• DG client software optionally supports the “connection pooling” feature. When enabled, programs can use the DG API to “close” the application’s connection “handle”, but the DG protocol connection persists in the software pool of dormant connections until the connection is potentially “reused” in a later DG API “open” call. If no such API call occurs, the connection will be closed when it ages out of the pool (“pooled connection timeout”), or its process ends, whichever comes first. Thus, DG TCP connections may remain open for longer than they are in use by the application when connection pooling is enabled.
• TCP Keepalive is a configuration option found on both IBM i and Windows OS platforms. It is commonly deployed in order to maintain TCP connections, including DG connections, in “intricate” or unstable networks.
• DG optionally supports .NET NEGOTIATE authentication and data encryption via Kerberos-AD SSO, including an NTLM SSO authentication-only fallback option where available/necessary.
• DG Windows-based servers (DSS, DG for Windows) optionally support SChannel-based TLS negotiation and data channel encryption, with multiple certificate verification options. ASNA recommend this option for connections over unsecured networks. By default a Win32-generated, self-signed, “session” certificate, created at server startup, is used to authenticate and secure the data channel. DG Windows servers may be configured, via Windows interfaces, to use and verify a properly configured certificate installed in the server’s “local machine” certificate store.
• DG IBM i-based servers (DG/400) optionally support GSK-based TLS negotiation and data channel encryption, with some certificate options. ASNA recommend this option for connections over unsecured networks, but only when a proper certificate is configured, via IBM i interfaces, for use with the DG/400 instance. By default, DG/400 uses a self-signed, “well-known” certificate, generated by ASNA Release Engineering, and configured during installation. This is only provided for testing purposes.
• When not using TLS, authenticated NEGOTIATE-based connections to Windows servers (DSS, DG for Windows) automatically inherit Kerberos data channel encryption. ASNA recommend this option (when TLS is not configured) for connections over secured AD networks.
• Unsecured, “clear text” connections are available for use in secured networks; this is only recommended in scenarios where all users are fully trusted and/or security resources are minimal.
• Windows client tools (DG Studio, DG Monitor) are used to configure client connection profiles (a.k.a., “database names”). By default, the tools create clear-text connection profiles. TLS options are available in “advanced” connection configuration dialogs, and NEGOTIATE may be enabled by specifying the user credential as “*DOMAIN”.
• DG .NET client programs support TLS via .NET SslStream (SChannel-based in Windows .NET Framework). DG .NET clients support NEGOTIATE via NegotiateStream.
• DG “Classic” programs may use an unsupported, prior-generation of DG protocol, which does not include TLS. The only Windows SSO option for these programs is NTLM.